BASES DE DATOS 
RELACIONALES 


E. RIVERO CORNELIO 


CUPARAN: INFO; 


bases 
de datos 
relacionales 


bases 
de datos 
relacionales 


E.RIVERO CORNELIO 


PARANINFO 


MADRID 


(O ENRIQUE RIVERO CORNELIO 
Madrid (España) 

O EDITORIAL PARANINFO, S.A. 
Madrid (España) 


Reservados los derechos para todos los países. Ninguna 

parte de esta publicación, incluido el diseño de la cubierta, 
puede ser reproducida, almacenada, o transmitida de ninguna 
forma, ni por ningún medio, sea éste electrónico, químico, 
mecánico, electro-óptico, grabación, fotocopia o cualquier 
otro, sin la previa autorización escrita por parte de la Editorial. 


Impreso en España 
Printed in Spain 


ISBN: 84-283-1652-X 


Depósito legal: M. 34.600.—1988 


PARANINFO ¡5 
PARA SA] Magallanes, 25 - 28015 MADRID (09225/38/10) 


Artes Gráficas BENZAL, S.A., Virtudes, 7 - 28010 MADRID 


Dedicatoria 


A Reme. 


Indice de materias 


TROBOGONS 4 AA a A A 11 
1. DEFINICIONES Y CONCEPTOS BASICOS -...0.0..o.oo.o.o..oo ooo... 15 
o IM a a O O O 0 e ON 115 
SAN a A A NS E A 15 
DES A A A 16 
PSsquemarconceptualldcidatOsA checo idad E a a tl ae eee let 17 
DA A e A 18 
RAI A a ora tes a e IO. 19 
NO A O E A A 20 
E E A A A A 20 
MALAS E a os a e cd O 21 
Extensión e mtensiontdejunal relación: oi Foot coo e e e 21 
E A a rt A A A A O 22 
SIigniticadordenunamelacion E: y to lado e e De ar 22 
Sienticad ode llos tdo RIOS lr aa fot oe E a e IAE de 23 
Zo AEGEBRAIREFACIONAT O" o td e al ee a ds 24 
DEA o A A 24 
Operadores Es. e a rs, ad RO o (AI ja ii la 24 
(A A O A A A NO 24 
Di A O AN ROO 24 
e E A A A OS 25 
BLOGUGIOS A A e O E SE A 25 
AE A A 25 
ET A AO A A E O 25 
(COCINE A a er ls a O a ee ss ai 26 
MI A AA IN O E, o 27 
Posibilidadidesoperaciones:de actualización ic... ionc ic das de E 30 
Opetación de rConplenentor to ya a late adsl 30 
Potencial iresivardelnalpobDra e loli TAO Elle dla IPR a 30 
(Operaciones a a a E A ASE 30 
Bropiedadestae Osho pEeradorES Vease sae a e lea elle y e E A 31 
MA a A A 32 
WMAlOtES HAM e a Ens tits e in A 34 


Indice de materias / 7 


INDICE DE MATERIAS 


Modelosrelaciónalde:datos: +estoas coros esse e 
Integtidad*de claves PLMAarías: chida e sols o a a e a 
ntegudadidemelcrcacia! loo o o a e nj ora Ao 

EJELCICIOSPRLODMESCOS LN IEA e ISE AUS E O 


3, CABCULO;REPACIONAD: 05 e de a a Sá 


Introducción informal al:cálculode EOplás: o... o aa 
NN A A A A O y 
Condiciones dercomparacionwió. De heno ses pliñers «Beal Drs a la 
Condiciones de spertenencia aro Eos ese tónS so ue ai a la 
Condiciones:cCOmpuestas” toto e Mero srl a led 
Guantificado existencial. Leo e A O e ca IO 
EtrantificadomMuniversal de li o oi a E det Ea IAE Teva 
EXPLOSIONES: vai e e a ps de al ir on ARE 
Variables tibres oy lIpadas” 0 Mii ts ER a A 

Calculado desPaplas Be ire oro a o IO 

Potencia expresiva del cálculo restringido de Tuplas .................. 

Lenguajes procedimentales («procedural») o... o... o... anses de 

Lenguajes relacionalmente completos ai. o id ete le As se 

Definición formalizada'del calculo de ÚUplas "bs laa e 

Introducción informal al cálculo de dominios ............ o... oo. ... 

Ejercicios propuestos «Mae + ado loto da A EA 


4; NORMAELZACIONS vi ss dl TE ESA od dd oa 


Condicionestdeintesridad Ae a io: 
PMschos “equivalentes. dto Due a a e O 5 
Reversibllidad:DoORyYUnCIOn Jolie. alar ato losetas e uz 00 TOTES a al 
DependenciasiiifcionalEs" ros e as ario 
Sistema de inferencia para dependencias funcionales ................... 
CIAUSUER: io de e ele O a at MS: 
Reconsideraciones Sobre las:cla Ves as a o o oO. 
Propagación de las dependencias funcionales al descomponer ............ 
Añomalias.de actualización dh era arts dd a Ae En Le 
Forma normaliderBoyCe-GOdAS se arta da ciade ae. AI a e EE MEN 
¡Tercera Jormarhormal: Pata Ud MA ls at le ER eN E 
Dependencias parciales Yi transitivas des. entere illes ad os a RS ATAR TRA 
Descomposición preservando las dependencias funcionales .............. 
Segunda forma normal rl Mc oo la e lol O SA 
Dependenciasanlurales ai ne bal dias ina ies Mars 05 NN. 
Sistema de inferencia para dependencias plurales ..................... 
Transformación de las dependencias plurales al descomponer ............ 
Amomalías de: actualizacióoniCOM DPS; une a a di 
Euartatormafaormal na. a a o a es o A te 
Dependenciastembebidas des sc sein rta alo PA NA 
Dependencias jerárquicas ets hs o a e A a 
Dependenclasivunciónales: aaa te rr de Me NS oca 
Forma normal de Proyección JUnción ina a rana RAIN MIE ena ad 
Formas normales ¡CO general. 2 te da o AO 
Normalizaoldesnormalizar .. ee. a A el RE ANS MA 
Dependencias feneralizadas no e o o o o 
Lambada O RS A RN 
Ejercicios PrOPuestos 0er. sm ais plis A o e AS. 


8 / Indice de materias 


INDICE DE MATERIAS 


SODIAGRANMIASIPARA DISEÑO” Dita or de 122 
Diasramtasinararayudar cn ie lt OISchO e. clara. Bei a aa O E y A 122 
Representacion de rCOImuatos de Valores acid. uno e 0 ta e e o 123 
Representación: delasociaciones DIDaTIAS: disc. oo... ce mans ole aa 124 
Representación de asociaciones binarias implícitas ................oo.o.. 128 
Eardinalidad yacohdiciones de imtegridad ...óo0.oo«o cago di... 130 
Diagrama de conjuntos y asociaciones —.......ooooocoocoocccooronomo.. 134 
Reslara e proparacionddesciayes. eg ie ie e a a 135 
Asociaciones implícitas entre relaciones UNAarias ...........o.oooooo oo... 137 
Asociaciones implicitas entre relaciones N-ariaS ...........o.oooooo oo... 138 
Rerlaracrdelticiontde Claves ada asa at ao ie a e apa 141 
Regla de agregación de rectángulos ............o.ooooooocmorommmo.r... 142 
Regla de supresión de rectángulos ..............ooooooooooooommo... 145 
Ejemplos de diagramas de conjuntos y asociaciones ......oooooo.oo.oo.o.. 148 
Representación de asociaciones entre asociaciones ........o.ooooooo o. .o.. 152 
Diarra ma RD Ri ens a a e ase a das da 153 
Representación de asociacionesin-ariasiós. era odia a aaa 160 
Redundancia de la regla de propagación de claves .................... 162 
Definicionide end ados da o ad a 163 
A 166 
BroductoldotasO CIA CIO OSM Ca ro a a al a ae 167 
Dependencia Apure rage td a a a le 173 
iros tunostdeldependencids: e a A aaa 176 
Uso de los diagramas RE/R en el diseño de estructuras IMS ............ 179 
El modelo de datos E/R (de entidades/relaciones) .................... 183 
MS ito A A O A 184 

6. METODO Y EJEMPLOS DE DISEÑO ...........oo.ooccocoooo o 190 
EA O e A A A O O 190 
INCOLDOrecIONdONALOres nulos occ a a e 192 
Obtencion del'esquema:relacional de diseño —.......<..<.<.< comme... 195 
it o o E E A A A A A 196 
IMecanIZacion de lPrOcesO SIdISEÑO aiii es ce ed o e ea AS 198 
EJE POS A A le le a a a a A Ma 199 
OS E A A 224 

ABPNDIGERASABIDO Praia 0 ao lo afan Y cd Aa da 227 

APENDICE B: Recordatorio de la notación utilizada ................... 229 

ARRNDICRESO peradorestlogiCOS . cemiadire a  l 230 

APENDICE D: Programa para relaciones entre empresas .............o.o... 232 

ARENDIGE E Prostama para dISODO.. 22700. 0 ls 234 
Deo A A 234 
Prada dato a E A e e 234 
Sada a A IO as A A E 235 
Aplicación alla BED UDIVErsitaTia: cra ra id a 236 


Indice de materias / 9 


INDICE DE MATERIAS 


APENDICE EF: Soluciones a los ejercicios propuestos .............oooooo. 
OA A ST 
ralculorrelacional es o a ld ra AA e AMADA 
INOTMAlIZACIO Nk italia ds an A 
Diagramastparardiseno Es Ms 0d, EAN AA Y IA 
Metodo MPejemplos e E A A O a TE 


10 / Indice de materias 


Prólogo 


Dentro de la tecnología informática, las técnicas de bases de datos han ido 
aumentando su importancia y sus aplicaciones en los últimos años. La razón 
para ello ha estado en la demanda, siempre creciente, de utilización de grandes 
masas de datos, frecuentemente integrados, y con requisitos de alta productivi- 
dad en su manejo, tanto en el desarrollo de aplicaciones por programadores 
profesionales, como por parte de usuarios finales. Las bases de datos han 
respondido a esta necesidad, permitiendo estructurar éstos con técnicas más 
formalizadas, de uso más sencillo y con mayor capacidad para reflejar su 
significado. 


En la búsqueda de estos objetivos, las bases de datos relacionales han 
supuesto un avance fundamental. Sus principios teóricos se establecieron y 
consolidaron en la década de los 70, y en la actual, la de los 80, están pasando 
del ámbito de la investigación al de las realizaciones prácticas, expandiéndose 
rápidamente sus aplicaciones. Al mismo tiempo, continúa la investigación teóri- 
ca, pues los conceptos relacionales forman una base sólida para la exploración 
de nuevas áreas, como por ejemplo el enriquecimiento semántico del modelo de 
datos, las bases de datos distribuidas, nuevos tipos de datos (gráficos, voz), uso 
«de técnicas de inteligencia artificial para formar bases de conocimiento y otros. 


El primer paso para utilizar una base de datos relacional es hacer un buen 
diseño de sus estructuras de datos. A ello va encaminado este libro, que, por 
tanto, no contempla otros aspectos como concurrencia de acceso, protección de 
la confidencialidad de datos, actualización de vistas, optimización de consultas, 
recuperación de datos, etc., temas todos ellos muy importantes para otros fines. 
El libro va orientado a conseguir diseñar adecuadamente estructuras relacionales 
de datos que sean coherentes con el significado de éstos. 


Para ello, el plan seguido es el siguiente: 


1) Exponer las definiciones básicas del modelo relacional de datos, así como 
el lenguaje llamado álgebra relacional, que es necesario para posterior- 
mente tratar la normalización de relaciones, basada en la utilización de 
operaciones algebraicas (fundamentalmente proyección y yunción). Esto 
se expone en los dos primeros capítulos. 
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2) Aunque no estrictamente necesario para el objetivo del libro, se incluye 
una descripción del lenguaje llamado cálculo relacional, por ser éste la 
base de otros que se usan en la práctica. Esto se encuentra en el tercer 
capítulo. 


3) Exponer los conceptos y teoría de normalización de relaciones (capítulo 
cuarto), fundamentales para comprender cómo conseguir un buen diseño. 
Sobre este tema existe una abundante bibliografía que, frecuentemente, o 
bien lo expone con una orientación muy matemática, apta sólo para 
especialistas, o bien lo presenta sin el rigor necesario al tratar de vulgari- 
zarlo excesivamente. Este libro pretende no caer en ninguno de estos 
extremos. 


4) En los dos últimos capítulos se propone un método de diseño basado, 
con algunas modificaciones, en los conceptos de entidad y relaciones. Se 
da una definición de entidad más formalizada de la que suele manejarse 
habitualmente, apoyada en los tipos de asociaciones, que no contradice 
ni elimina el uso intuitivo de este concepto, sino que más bien lo refuerza 
haciéndolo más preciso. Este método se aplica a varios casos prácticos. 


Al final de cada capítulo, excepto el primero, se proponen algunos ejercicios 
cuyas soluciones se muestran en el apéndice. El lector podrá ejercitar y aclarar 
en ellos algunos de los conceptos expuestos, que además se ha intentado que 
vayan acompañados en el texto por numerosos ejemplos. Estos últimos, junto 
con los ejercicios al final de cada capítulo y los casos prácticos del último, 
pretenden también desarrollar en el lector una percepción de lo complejo, 
esquivo y multiforme que es el aspecto semántico de los datos. Para el lector 
que desee profundizar en esto, es recomendable la lectura del libro del señor 
Kent Data and Reality, citado en la bibliografía. 


En las definiciones ha sido inevitable usar términos del lenguaje matemático 
para dar precisión a los conceptos, pero se ha intentado siempre reducir el 
formalismo matemático a lo imprescindible, dando prioridad a la claridad y 
comprensión de los conceptos antes que al aparato que los soporta. Por ello no 
se incluyen, en general, demostraciones de las propiedades que se enuncian, salvo 
en algunas pocas ocasiones en que el resultado que se demuestra es muy 
importante para el desarrollo posterior, o a modo ilustrativo del tipo de 
demostraciones que suele haber en la literatura especializada. El lector que desee 
profundizar en este aspecto puede recurrir a algunos de los libros citados en la 
bibliografía. En resumen, se ha pretendido que no sea necesario un previo 
conocimiento matemático especializado para la lectura y comprensión de esta 
obra, que aspira a ser útil tanto a los profesionales de proceso de datos como 
a los estudiantes interesados por estas materias. 


El autor, que ejerce su actividad profesional en IBM S.A.E., desea aclarar 
que todos los conceptos y puntos de vista expuestos son de su exclusiva 
responsabilidad y no reflejan necesariamente la posición de IBM sobre estos 
temas. 
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También desea agradecer el ánimo y colaboración que le han prestado 
algunos colegas y compañeros, especialmente el señor J. J. Kuntz. 


Y finalmente, siendo consciente de que esta obra es mejoráble, pide la 
benevolencia del lector para las carencias e incorrecciones que pueda tener, y 
sólo le queda desearle esperanzadamente una lectura interesante, instructiva y 
provechosa. 
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Definiciones 
y conceptos básicos 


INFORMACION Y DATOS 
Información 


Este libro trata, en términos generales, de cómo representar la información 
mediante datos. Dado que tanto el concepto de información como el de datos 
se utilizan en muy diferentes contextos y con múltiples matices, vamos a intentar 
aquí acotar el significado de estas palabras en el ámbito que nos interesa. 


La información puede adoptar formas muy diversas. Por ejemplo: 


e Signos escritos: Libros, periódicos, facturas, letras de cambio, apuntes de 
contabilidad, cartas, jeroglíficos, dibujos, partituras musicales, inscripcio- 
nes en piedra, en papiro, etc. 


e Sonidos: Lenguaje hablado, música, los silbidos que usan en la isla de la 
Gomera, etc. 


e Señales de cualquier tipo: Las señales de tráfico, los lenguajes con banderas 
entre los barcos, las señales de humo entre los indios del lejano Oeste, los 
garbanzos que Pulgarcito arrojaba para marcar el camino, etc. 


En todos estos ejemplos hay algo común: un mensaje. Es decir, unas ideas 
vertidas por un ser humano sobre un soporte material para que otro ser humano 
las reciba. Las ideas representadas por el mensaje son la información de éste. 
Para nosotros, por tanto, el concepto de información va unido al proceso de la 
comunicación humana. 


Así, no estamos aquí interesados en las ideas que puedan surgir en la mente 
de un observador al recibir estímulos procedentes de fenómenos naturales, 
aunque podrían considerarse información en un sentido amplio. No estamos, por 
ejemplo, interesados en los mensajes de comunicación entre animales, que 
pueden en cambio ser objeto de estudio y aporte de información para un biólogo 
o un cazador. Tampoco consideraremos como información los sentimientos que 
una hermosa puesta de sol pueda provocar en una persona sensible. 
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En cambio, sí entrarían en el concepto de información enunciado los senti- 
mientos provocados en una persona al contemplar un cuadro que represente una 
puesta de sol. Aquí existe un proceso de comunicación humana. El cuadro es 
un mensaje, fruto consciente de una mente humana que desea comunicar parte 
de su mundo interior a otras, y aporta una información, que es el conjunto de 
emociones y sentimientos que surgen en la mente de quien lo contempla. 


Nuestro ámbito de estudio es más restringido. Sólo nos interesa la informa- 
ción que pueda representarse en mensajes procesables por máquinas. Los orde- 
nadores son máquinas que procesan cadenas de signos o caracteres, a gran 
velocidad y en grandes volúmenes. 


Por tanto, nos restringiremos a la información aportada por mensajes 
formados por cadenas de signos. 


Datos 


Analicemos qué tipos de mensajes son los que nos interesan. 


Consideraremos mensajes construidos con signos, combinando éstos en uni- 
dades de complejidad creciente ateniéndose a unas reglas que vienen definidas 
por el lenguaje en que se escribe el mensaje. 


Para construir estos mensajes partimos de un conjunto finito que llamaremos 
alfabeto. A los elementos de este conjunto los llamaremos signos. 


Concatenando signos del alfabeto se forman unas cadenas, de longitud finita. 
No todas las combinaciones posibles de signos forman cadenas válidas en un 
lenguaje determinado. A las que lo son, las llamaremos palabras. El conjunto 
de todas las palabras forma el vocabulario del lenguaje. (Esta definición de 
palabra sería demasiado general para estudiar un idioma, pues incluiría como 
palabras a los signos de puntuación, pero es suficiente para nuestro propósito.) 


Un mensaje se construye concatenando un número finito de palabras, según 
unas reglas definidas en la gramática del lenguaje, y aporta al que lo recibe una 
información constituida por todas las ideas, emociones, sentimientos, etc., que 
aparecen en su mente como consecuencia de recibirlo. Llamaremos significado 
de un mensaje a la información que éste aporta a la persona que lo recibe. De 
acuerdo con esto, el significado de un mensaje es algo subjetivo, que depende de 
la persona receptora. Así, por ejemplo, un libro no tiene apenas significado para 
un analfabeto, puesto que a su mente no llega el mensaje que contiene. 


En principio, el lenguaje en que se escribe un mensaje puede ser cualquiera. 
Si se utiliza un lenguaje humano de uso común, por ejemplo el castellano, el 
francés o el latín (en su día fue el más común), diremos que el mensaje no tiene 
formato, o que está escrito en texto libre. Este tipo de mensajes y la información 
por ellos representada es objeto de numerosas aplicaciones de los ordenadores 
en las áreas de proceso y edición de textos, tratamiento de documentos y 
automatización de oficinas. Pero no, tampoco es el objeto de nuestro estudio. 


Muy frecuentemente las aplicaciones de los ordenadores procesan mensajes 
construidos con un lenguaje muy simple, en el que normalmente cualquier 
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combinación obtenida concatenando palabras del vocabulario constituye un 
mensaje formalmente válido. Cada palabra de un mensaje tiene un significado 
predefinido en función de la posición que ocupa dentro de él. Las palabras que 
forman el vocabulario se llaman datos. 


Usando una terminología más común en informática, cada mensaje es un 
registro y cada registro contiene varias palabras cuyo significado está ligado a 
su posición dentro del registro. El «hueco» o posición que dentro de cada 
registro ocupa un dato se llama campo. Los registros que tienen campos con 
el mismo significado predefinido se suelen agrupar en conjuntos llamados 
ficheros o archivos. 


Los mensajes que nos interesan son un subtipo de estos registros, formado 
por aquellos que tienen un número fijo de campos. En este caso los conjuntos 
de registros de igual significado, y por consiguiente con el mismo número de 
campos, se llaman tablas o relaciones. Los campos se suelen llamar atributos. 


Este tipo de registros, sus conjuntos o tablas, sus componentes, atributos y 
datos, y la información representada por ellos, constituyen finalmente la materia 
que vamos a explorar en las páginas siguientes. 


ESQUEMA CONCEPTUAL DE DATOS 


Sea una empresa o entidad de cualquier tipo que desea almacenar datos que 
reflejan información sobre sus actividades. En la figura siguiente se representan 
los pasos para conseguirlo. 


Hay que empezar acotando qué parcela del mundo exterior nos interesa 
representar en los datos. Estará formada por todos los objetos y acontecimientos 
cuyo conocimiento nos permita una mejor gestión de nuestras actividades. 


El diseñador, o analista de datos, debe aprehender, comprender y conceptua- 
lizar este mundo, transformándolo en un conjunto de ideas y definiciones, que 
formen una imagen fiel del comportamiento del mundo real. A esta imagen del 
mundo exterior la llamaremos modelo conceptual. Para construir un buen 
modelo, el analista debe utilizar una gran dosis de procesos mentales de 
abstracción, análisis y síntesis. Necesitará además la colaboración de personal 
directivo. 


Una vez definido el modelo conceptual, el analista lo transforma en una 
descripción de datos, atributos y tablas, incluyendo las posibles interrelaciones 
entre estos elementos y su significado. A esta descripción la llamaremos esquema 
conceptual de datos. 


A la operación de transformar el modelo conceptual en un esquema concep- 
tual la llamaremos diseño lógico de datos (por ello, al esquema conceptual 
también lo llamaremos a veces esquema de diseño). 


Una vez definido el esquema conceptual, hay que traducirlo a estructuras 
almacenables en soportes físicos controlados por el ordenador, normalmente 
discos magnéticos. Esta transformación se suele llamar diseño físico de datos. 
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MUNDO EXTERIOR 


MODELO 
CONCEPTUAL 


ESQUEMA 
CONCEPTUAL 


(ANALISTA) 


.. Un buen diseño lógico debe producir un esquema conceptual que sea una 
imagen fiel y completa del modelo conceptual, incluyendo algunas interrelaciones 


y condiciones semánticas, es decir, aquellas que son consecuencia del significado 
de los datos. 


Por ello vamos a explorar en los siguientes capítulos algunos tipos de 
condiciones semánticas y cómo expresarlas en el esquema conceptual. En los 
últimos capítulos propondremos un método y una serie de reglas que sirven de 
ayuda al analista en el proceso de diseño lógico. 


Empezaremos, en los apartados siguientes, definiendo los objetos con los que 
se construye el esquema conceptual: atributos, tablas, dominios. etc. 


DOMINIOS 


Un dominio, Di, es un conjunto de palabras, es decir, de ristras de caracteres 
tomados de un alfabeto dado. En general nos interesará definir también un 
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conjunto de operadores sobre estas palabras, para poder manipularlas. Por 
ejemplo, operaciones aritméticas y de comparación. 


Un dominio puede ser un conjunto finito o infinito: 


Ejemplos: 
e Alfabeto: (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, /, —, ?). 
e Dominio D;: (0, 10, 11, 12, 13, 14, 15). 
e Dominio D,: Conjunto de los números naturales. 
e Dominio D: (0, 1, 2, 1/2, 1/3, 2/3). 
e Dominio D,: Conjunto de los números racionales. 
e Dominio Ds: (0, 1, 2, —1, —2). 
e Dominio Ds: (0, 3,14, —3,14). 
D, y D, son infinitos. 
El producto cartesiano de dos conjuntos, D, y D;, es otro conjunto, cuyos 


elementos son todas las parejas de valores que se pueden formar tomando un 
elemento de D, y otro de D,. Lo representamos como (D; x Dj). 


Ejemplo: 
(D,x Ds) es el conjunto: (<0, 0», <0, 3,14), <0, —3,14), <1, 0), <1, 3,14), 
Ll — IA O 3,14): (2, 3,14% <—L1, 0), (—1, 3,14), <—1, 3,14), 


<—2, 0), (—2, 3,14», X-2, —3,14)). 


RELACIONES 


Supongamos un conjunto, D, de dominios: 
D(D, 4D. DS 27D): 


Definamos entre ellos un criterio de orden que nos permita colocarlos a todos 
en una secuencia de menor a mayor (o de precedente a siguiente): 


Secuencia: D, <D,<D5<---<D,. 


Formemos ahora un producto cartesiano con algunos o todos los dominios 
de D: 


D,xD,x-"xD,. 


Los factores del producto anterior pueden estar repetidos. Por tanto, puede 
ser k=n,k<n o k>n. 


Los factores los colocamos en el orden definido por la secuencia citada 
anteriormente. 
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Ejemplo: 
D, xD,xD3; D,xD, xD4; D, xD,xD,xD:;; etc. 
Una relación, R, es un subconjunto finito de un producto cartesiano formado 


con las reglas expuestas. Si representamos con < la propiedad de que un 
conjunto esté contenido en otro tendríamos: 


R<(D,xD,xD;,x---xD,). 
Cada elemento de una relación se llama tupla. 
Se llama grado de una tupla al número de componentes que tiene. El grado 


de una relación es el de sus tuplas. 


Como R es un conjunto, todas sus tuplas deben ser diferentes. Es decir, en 
una relación no puede haber tuplas repetidas. Además, no hay un criterio de 
orden definido entre ellas. 


ATRIBUTOS 
A cada dominio que participa en una relación se le da un nombre que lo 
identifica de forma única para esa relación. 

Entonces una tupla puede representarse o bien como una lista ordenada de 
valores: 

t=<t,, tz, t3, ..., t,», donde: 


t, = Valor del primer dominio, 
t,= Valor del segundo dominio, 
t¿= Valor del tercer dominio, etc. 


O bien como una lista desordenada de valores identificados por sus nombres 
de atributos: 


t=(ATR3=t,, ATR2=t,, ATRI=t,, ..., ATRk=1,). 


CLAVES 


Ya hemos dicho que como una relación R es un conjunto, todas sus tuplas 
han de ser diferentes, es decir, no se repiten sus valores. 


A todo conjunto de atributos con esta propiedad se le llama superclave. Sea 
una superclave, tal que la formada por los atributos A, B, C y D de una relación 
R. Si no es posible quitarle ninguno de sus atributos sin que pierda su cualidad 
de superclave, se dice que es una clave de R. En definitiva, una clave de R es 
un conjunto de atributos de R que no puede tomar valores repetidos, y tal que 
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cualquier subconjunto suyo sí puede tomar valores repetidos, es decir, no es una 
superclave. 


Toda relación tiene al menos una clave. Pero puede tener más de una. Esto 
depende del significado de la relación. 


Entre los valores que toma una clave de una relación y las tuplas de ésta 
existe una correspondencia biunívoca, de modo que las claves pueden utilizarse 
como identificaciones de las tuplas de la relación. El único medio de dirigirnos 
a una tupla determinada, distinguiéndola de todas las demás, es mediante los 
valores de los atributos de alguna de sus claves. 


TABLAS 


Si colocamos todas las tuplas de una relación una debajo de otra, alineando 
los componentes correspondientes de cada atributo en una columna, y colocamos 
en la cabecera de cada columna el nombre de su atributo, obtenemos una 
representación de la relación a la que designaremos con el nombre de TABLA. 


Cada tupla forma una fila de la tabla. 


EXTENSION E INTENSION DE UNA RELACION 
Al transcurrir el tiempo, una relación puede sufrir modificaciones para reflejar 
los cambios del mundo real que representa. 


Al añadir, borrar o modificar alguna tupla de una relación, ésta se transforma 
en otra distinta, pero con las mismas características. 


Ejemplos: 
e Relación de proveedores el día 1 de enero: 


Núm. proveedor Nombre 
100 Pepe 
200 Paco 


e Relación de proveedores el día 1 de febrero: 


Núm. proveedor Nombre 
100 Pepe 
200 Paco 
300 Pablo 


Aquellas propiedades de una relación que no varían a lo largo del tiempo se 
conocen con el nombre de INTENSION. Dicho de otro modo, la intensión viene 
definida por todas las propiedades comunes a toda la familia de relaciones 
obtenibles al actualizar una dada. 
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Estas características invariantes al actualizar una relación son las siguientes: 


e El nombre de la relación. 
e Los dominios. 


e El producto cartesiano de dominios sobre el que se construye la 
relación. 


e Los nombres de los atributos. 


La intensión también la conoceremos como ESQUEMA de la relación. 
Llamaremos extensión de una relación a las tuplas que contiene en un momento 
dado, que pueden variar al actualizarla. 


El esquema se representa poniendo el nombre de la relación, seguido por los 
nombres de los atributos entre paréntesis y separados por comas. Así por 
ejemplo, R(A, B, C) es el esquema de una relación R con tres atributos, A, B y C. 


BASE DE DATOS 


Llamaremos base de datos a un conjunto finito de esquemas de relaciones. 


SIGNIFICADO DE UNA RELACION 


En apartados precedentes llamábamos significado de un registro a la informa- 
ción que éste aporta a la persona que lo recibe, con lo que el significado es algo 
subjetivo, dependiente de la persona receptora. Vamos a restringir este concepto 
para hacerlo algo menos subjetivo. 


Cada tupla de una relación indica que sus componentes están ligados entre sí 
por unas determinadas propiedades, que constituyen el significado de la relación. 


Dicho de otra forma, las tuplas que están contenidas en una relación no se 
han extraído al azar del producto cartesiano de sus dominios, D, xD,x---*xD,, 
sino de acuerdo con su significado. 


Este significado es asignado por el analista cuando define el esquema con- 
ceptual. 


Ejemplo: 


Sea el esquema EM(DNI, SS, SU, FI). Su significado, asignado por el analista, 
podría venir definido por las propiedades siguientes: 


«Cada fila de la tabla EM se refiere a un empleado de la empresa. La columna 
DNI contiene el DNI del empleado. La columna SS su número de Seguridad 
Social. La SU su sueldo. La FI su fecha de ingreso en la empresa.» 


Estas condiciones hacen que no sea válido incluir en EM tuplas con valores 
cualesquiera, sino sólo si éstos corresponden con los de un empleado. 
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La información que una tupla determinada aporta a un usuario viene definida 
en parte por el significado de la relación y en parte por los valores de sus 
atributos. 


Asignar significado a un esquema de relación no es imprescindible desde un 
punto de vista mecanicista del modelo relacional, pues aun cuando las tuplas 
que se incluyeran en una relación se hubieran elegido al azar, se seguiría teniendo 
una relación formalmente válida. 


Existen intentos de extensión del modelo relacional básico para que el sistema 
capture y gestione algo más del significado de las relaciones. 


SIGNIFICADO DE LOS DOMINIOS 


En el modelo relacional básico, de acuerdo con la definición dada anterior- 
mente, un dominio es un conjunto, finito o infinito, de palabras formadas con 
un alfabeto finito entre las que existe un criterio de orden. Este criterio de orden 
puede ser común para varios dominios, por lo que éstos pueden participar unos 
con otros en ciertas operaciones que impliquen comparación y orden. Por 
ejemplo, tiene sentido hablar de unión, intersección, etc., entre ellos. 


Se podría concebir un modelo relacional más avanzado en el que los 
dominios tuvieran un significado. Por ejemplo: 


D,: Conjunto de fechas de nacimiento. 
D,: Conjunto de los sueldos en pesetas de los empleados. 
D,: Conjunto de los nombres de los empleados. 


Entonces se podrían restringir las operaciones de comparación y orden a 
elementos y subconjuntos de un mismo dominio. Así se aseguraría evitar hacer 
operaciones sin sentido (por ejemplo comparar fechas con sueldos). Nosotros no 
lo consideraremos así, mientras no se diga explícitamente lo contrario. 
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Algebra relacional 


DEFINICION 


El álgebra relacional es un sistema cerrado de operaciones definidas sobre 
relaciones. Es decir, tanto los operandos como los resultados son relaciones. 
Esto permite construir fórmulas o expresiones combinando unas operaciones con 
otras, de manera que los resultados de unas sean operando de otras. 


Con más precisión: 


Dado un conjunto de dominios, D=(D,, D,,..., D,), sea R el conjunto de todas las 
relaciones posibles que se puedan construir sobre D. El álgebra relacional es un 
sistema formado por R y unos operadores cuyos operandos y resultados también 
pertenecen a R. 


Vamos a describir a continuación estos operadores. 


OPERADORES 
Unión 
RusS. (Como unión de conjuntos.) 
El resultado es una relación que incluye a todas las tuplas de R y todas las 


de S, y ninguna más. Si hubiera alguna repetida en R y S, sólo figurará una vez 
en el resultado. 


R y S deben ser relaciones del mismo grado 


Diferencia 


R—S. (Como diferencia de conjuntos.) 
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El resultado es una relación que incluye a todas las tuplas de R que no están 
en $. 


R y S deben ser relacienes del mismo grado. 


intersección 
R NS. (Como intersección de conjuntos.) 
El resultado es una relación que incluye a todas las tuplas de R que también 


están en S. 
R y S deben ser relaciones del mismo grado. 


Producto 

RxS. 

El resultado incluye a todas las tuplas posibles que se obtienen concatenando 
una de R con otra de $. 

También lo llamaremos producto cartesiano de las relaciones R y $. 

R y S pueden ser relaciones cualesquiera. 


Proyección 


P(A,, Az, ..., A,) (R): Proyección de la relación R sobre los atributos 
ARMA olas A: 
El resultado se forma extrayendo de la relación R los atributos o columnas 
A, A,,..., Ar, y eliminando luego las tuplas que resulten repetidas, si las hay. 


A veces, para abreviar, representaremos a una proyección, por ejemplo la 
P(X, Y, Z) (R), como R[X, Y, Z]. 


Selección 
S(F) (R): Selección de la relación R de acuerdo con la fórmula F. 


El resultado se forma extrayendo de la relación R todas las tuplas que 
cumplan las condiciones expresadas en la fórmula F. 


Esta fórmula se construye con operandos que pueden ser constantes, o 
atributos de R, ligados entre sí por los operadores definidos sobre los respectivos 
dominios. Vamos a suponer que son operadores aritméticos (+, —, *, /, *x*), de 
comparación (>, <, =, >=, <=,"1=), y lógicos (v, a, 1). (El significado 
de estos operadores lógicos se describe en uno de los apéndices.) 
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Ejemplo: 
Si R tiene los atributos A, B, C y D, fórmulas válidas serían: 
A=100 
(A=100) n(B> 200) 
(A =100) 1 (B>200) (C+8 <D xx 2) 
Con cierta frecuencia tendremos que referirnos a los valores de un atributo 


que corresponden a un valor fijo de otro. Para ello emplearemos la notación 
siguiente: 


R(X=x, Y), 


que representa parejas de valores formadas con todos los valores del atributo Y 
asociados a un determinado valor, x, de un atributo X, en una extensión de la 
relación R. 


Esto lo podemos expresar más precisamente mediante las operaciones de 
proyección de la forma siguiente: 


Si X e Y son atributos de R, (R(X=a, Y))=(P(X, Y)(S(X=a)(R))). Normal- 
mente no necesitaremos indicar que X es el atributo cuyo valor fijamos, sino que 
se podrá deducir del contexto. En este caso, la notación anterior se simplificará, 
quedando así: R(a, Y). 


Cociente 


Sean R y S relaciones de grado (m-+n) y (n), respectivamente. Esto lo 
representaremos por Rm +n) Sn: SUPpongamos que $ no es vacía. 


Entonces, se define el cociente entre R y S, que lo representaremos por (R /S), 
como el conjunto de todas las tuplas de grado m tales que, al concatenarlas con 
todas las tuplas de S, producen tuplas contenidas en R. 


R S (R/S) 


*KÁ——— m ——> «KE n => “—Kh— n —> a 


he 


Es decir, interpretando el dibujo anterior, se incluyen en (R/S) las partes 
izquierdas X de todas las tuplas de R tales que al hallar ((R /S) x S), se obtengan 
tuplas <X, Y> que están contenidas en R. O sea, <X> se incluye en (R/S) si y 
sólo si (<X>xS<R (el signo < significa «contenido en»). 


Xx —— 
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Se llama cociente por analogía: 


(RISAS S) .s R 
, y A Dividendo 

E i.. Divisor 

... Cociente 


Yunción 


Se representa R Y S(¡C]j). 

Se lee: Yunción de R y S, mediante el operador de comparación C sobre las 
columnas i de R y j de S. 

C es un operador de comparación (>, <, =, >=, <=, “1=). 

i y j son atributos de R y S, respectivamente. 

El resultado es el conjunto de todas las tuplas formadas concatenando una 
de R con otra de S de manera que se cumpla la condición (1 Cj). 


Equiyunción: Cuando la comparación es por igualdad (o sea, el operador C 
es el signo =). 


Yunción natural: La representaremos por (R Y S), o también por (R*S). (El 
signo * lo usamos también para representar la operación aritmética de multipli- 
car. El significado de * en cada caso vendrá definido por los operandos a los 
que se aplica. Si son relaciones, se tratará de una yunción natural, si son 
variables aritméticas, de una multiplicación. En todo caso, el contexto indicará 
claramente a cuál de ellos se refiere.) 


Sean dos relaciones R y S que tienen algunos atributos iguales (es decir, 
columnas homónimas). La yunción natural es el resultado de: 


1) Concatenar todas las tuplas de R y S. (es decir, hallar el producto R x 5). 


2) Seleccionar de entre estas tuplas concatenadas las que tengan iguales 
valores en todas sus columnas homónimas. 


3) Suprimir una columna de cada dos homónimas en el resultado. 


Si R y S no tienen atributos comunes, la yunción natural será igual al 
producto: R*S=R xS. 


La yunción natural es asociativa y conmutativa. Esto nos permite definir la 
yunción natural para n operandos. Así tendremos: 


RxS*T=(R*S)xT=Rx(S*T)=(R * T)*S 
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Al ayuntar dos relaciones, no todas las tuplas presentes en los operandos 
aparecen en el resultado. Algunas pueden perderse. Dada 


R=R,¡*R>,x*R3x---*R,, 


diremos que todas las tuplas presentes en R,, R,, R3,... R,, también aparecen 
en R si las R,, R,,... R,, puedan obtenerse proyectando R. 


Ejemplos: 
(Suponemos que todos los atributos están definidos sobre el mismo dominio.) 


Unión, intersección, producto cartesiano, diferencia, proyección y selección: 


Sie PDA CES [E 
blgja 
del cami 

R1nS1 
d Saf 

R1xSl |A|B 

ab 

al|b 

dalla 

d a 

cb.b 

c 1D 
R1—S1 | P(A, CRI) 

0 A le 

cal bull d 


S(B=b(RI)| A | B | E | 
0 DE 
rl o E! 
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Cociente: q 
SQAFCA DD 
ed 
e f 
R2/S2 |A | B L 
al|b k 
e ld 
Yunción: - 
S3 DE . 
3 1 6 
03112 


R3 Y S3(B<D) 


Yunción natural: 


€. (4D R4x5S4xT4 

cd L 
A 

e ld 

ce 

d|b 


(Puede verse en el ejemplo anterior que la tupla <b bf) de R4 no aparece en 
R4 x S4,) 
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POSIBILIDAD DE OPERACIONES DE ACTUALIZACION 
Pueden usarse para ello los operadores de unión y diferencia. 


Ejemplos: 

1) Insertar la tupla <100, a, b> en R: 
R uv (<100, a, b>) 

2) Borrar la tupla <100, a, b) de R: 
R—(<100, a, b»). 


OPERACION DE COMPLEMENTO 


No hemos definido en el álgebra relacional una operación de complemento, 
porque el conjunto de tuplas complementario de una relación R, no será, en 
general, otra relación de R. 


Se podría haber intentado definirlo como una relación (—R), tal que: 
(—R)=(D,xD,xD;x --- xD,)—(R) 


(donde D,, D,,..., D,, son los dominios usados en R). Si alguno de los dominios 
es infinito, también lo será (—R), por lo que ésta no será una relación válida. 


No usaremos operaciones de complemento. 


POTENCIA EXPRESIVA DEL ALGEBRA 


Hemos incluido en el álgebra los operadores unión, intersección, diferencia, 
cociente, producto cartesiano, proyección, selección y yunción. Se podrían inven- 
tar más operadores, pero es innecesario si nos limitamos a tener en el álgebra 
tanto poder expresivo como en el cálculo, que se verá en el próximo capítulo. 


El álgebra relacional es un lenguaje relacionalmente completo. Esto significa 
que tiene la misma potencia de expresión que el cálculo relacional. Es decir, 
cualquier fórmula de álgebra relacional es expresable en una sentencia de cálculo 
relacional, y viceversa. 


Por tanto, no es necesario inventar más operadores, a no ser que queramos 
dotar al álgebra de más potencia expresiva que el cálculo. Por ejemplo, el 
lenguaje relacional QBE (Query By Example) permite algunas operaciones no 
expresables en cálculo o álgebra. 


OPERACIONES PRIMITIVAS 


Hemos incluido en álgebra ocho operadores: unión, intersección, diferencia, 
cociente, producto cartesiano, proyección, selección y Yunción (U, M, =, /, X, 
PS, Y). 
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No son todos ellos necesarios. Algunos pueden expresarse en función de 
otros. 


Un conjunto de operadores primitivo, es decir, que ninguno de ellos puede 
expresarse en función de los otros, es el siguiente: 


US$, E 8. 

Veamos cómo expresar los otros tres en función de estos cinco. 
Intersección: 

(R A S)=(R —(R —S)). 

Yunción: 


(R Y S(¡Cj) =S(i C(r+j)(R xS), (donde r es el grado de R). 


División (R de grado m+n, S de grado n): 


Sea T=P(1, 2,..., m)(R). Entonces: 
(R/S)=T—P(1, 2,..., m((TxS)—R). 


PROPIEDADES DE LOS OPERADORES 


Ya hemos visto cómo algunos operadores pueden expresarse en función de 
otros. Un estudio más a fondo de las propiedades de los operadores es prerrequi- 
sito para poder optimizar la evaluación de expresiones. Esto nos plantea dos 
problemas: 


1) transformar una expresión en otra equivalente; 
2) determinar si la equivalente puede evaluarse en un tiempo más corto. 
Para resolver el primero hay que conocer las propiedades de los operadores. 
Citaremos, a modo de ejemplo: 
1) u es conmutativo y asociativo: 
(AuUB)uC=Au(BucC). 
2) Análogamente n. 
3) Propiedad distributiva de u y Mm: 
An(BuC)=(AnB)U(ANC). 
4) Propiedad conmutativa de la selección y el producto cartesiano: 
S(Fl a F2)(A x B)=(S(F1)(A)) x (S(F2)(B)), 
donde la fórmula Fl sólo se refiere a los atributos de A y la F2 a los de B. 
Dos expresiones son equivalentes cuando dan el mismo resultado para todos 
los valores posibles de las variables. 


Entre varias expresiones equivalentes elegiremos la que pueda evaluarse en 
menos tiempo, es decir, empleando menos operaciones elementales. 
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Ejemplo: 


Sea 

R(A, B) 

S(B, C) 

Tl =P(C)(S(A =a)(R +*S)). 


Esta expresión es equivalente a: 
T2=P(C)((P(B)(S(A =a)(R))) * S) 


Sin embargo, la expresión T2 es preferible, pues, en principio, se evaluará en 
menos tiempo que Tl. 


Importancia de la optimización 


Gracias al proceso de formalización se consigue poder expresar en fórmulas 
los procesos que sobre ficheros tradicionales secuenciales se reflejaban en organi- 
gramas con varios pasos (clasificación, enfrentamiento de maestro con movimien- 
to, selección). Y además, el sistema puede optimizar estos procesos (antes esta 
labor tenía que hacerse basándose en la intuición y la experiencia). 


Importancia del cálculo (o el álgebra) 
Son los lenguajes patrón, que permiten comparar la potencia expresiva de 
otros. 


Además, si las sentencias de un lenguaje son expresables en cálculo (o 
álgebra), inmediatamente le son aplicables los algoritmos de optimización desa- 
rrollados para aquél. 


VISTAS 


Otra consecuencia importante de la estructura de sistema cerrado que tiene el 
álgebra es el concepto y utilización de vistas. 


El que los operandos de una expresión puedan a su vez ser expresiones, 
permite tener expresiones prefabricadas que se usan para construir otras más 
complejas. 


Se llama vista a una expresión o fórmula algebraica a la que se le asigna un 
nombre. Este nombre puede utilizarse como operando en la construcción de 
nuevas fórmulas, a las que también se les puede asignar un nombre a su vez. 


El uso de vistas puede aplicarse para: 


e Proteger la confidencialidad de acceso a los datos. 
e Simplificar la formulación de expresiones complejas. 


e Evitar que cambios en el diseño afecten a los programas ya existentes. 
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Ejemplo 1: 
Consideremos las relaciones EMP(NUEM, NOME, SUELDO, NUDE) y 
DEP(NUDE, NOMDE). 


EMP: Contiene una tupla por cada empleado. 
DEP: Contiene una tupla por cada departamento. 
NUEM: Número identificador de empleado (clave). 
NOME: Nombre de empleado. 

NUDE: Número de departamento (clave de DEP). 
NOMDE: Nombre de departamento. 


Supongamos que un usuario desea acceder a los datos de los empleados, pero no 
queremos permitirle que acceda a los datos de sueldos. Para ello podemos definir 
la vista siguiente: 


EMPUBLI=P (NUEM, NOME, NUDE) (EMP) 
Si ahora autorizamos al usuario a emplear en la construcción de fórmulas la vista 
EMPUBLI, pero no la tabla EMP, estaremos impidiéndole el acceso a los datos 
confidenciales de sueldos. 
Ejemplo 2: 


Queremos hallar, con las relaciones del ejemplo anterior, los nombres de los 
empleados que trabajan en el departamento cuyo nombre es DA. 


Para ello podemos definir la vista EMPDEP: 
EMPDEP =EMP x DEP 
Los datos de los empleados del departamento DA vienen dados por la vista: 
V1=S (NOMDE=DA) (EMPDEP) 
Sus nombres vienen dados por: 
P (NOME) (V1) 
En definitiva, hemos construido gradualmente la fórmula: 
P (NOME) (S(NOMDE=DA) (EMP x DEP)) 


Ejemplo 3: 

Sea la relación PED (AR, PR, CA, NP). 
PED: Contiene una tupla por cada pedido. 
AR: Número de Artículo. 

PR: Número de Proveedor. 
CA: Cantidad pedida. 

NP: Nombre del Proveedor. 
Clave: (AR, PR). 


Decidimos cambiar este diseño sustituyendo la relación PED por las siguientes: 


PEDI (AR, PR, CA), (Clave: (AR, PR)) 
PROV (PR, NP), (Clave: PR) 


Entonces todas las fórmulas en las que se haya empleado PED dejan de ser 
válidas. Sin embargo, si definimos la siguiente vista (con el mismo nombre), siguen 
siendo válidas: 


PED=PEDIx PROV 
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Es decir, los programas que usaban la tabla PED original en modo lectura (o sea 
para consultas), siguen siendo válidos si usan la nueva vista. Los programas que 
actualizaban la tabla PED original pueden no ser válidos al intentar trabajar con 
la vista PED. Bajo qué condiciones serán válidos o no constituye un problema 
que se sale de nuestros objetivos, por lo que no vamos a entrar en él. 


VALORES NULOS 


El permitir que algunos atributos puedan tomar valores nulos tiene efectos 
importantes en las definiciones anteriores, que deben ser revisadas y adaptadas. 
Vamos a tratar de exponer brevemente algunos de ellos. 


Se suelen emplear los valores nulos para representar información incompleta. 
Representaremos los valores nulos con el signo ?. 


Ejemplo: 
Si en la relación EMPLEADOS (NOMBRE, EDAD), quisiéramos dar de alta ai 


empleado PEPE sin saber su edad, insertaríamos la tupla «PEPE, ?». De modo 
que el valor nuio, ?, puede interpretarse como «desconocido». 


Una primera consideración a tener en cuenta es que puede haber distintos 
tipos de valores nulos en este sentido de información incompleta. En efecto, un 
valor puede ser menos «desconocido» que otro, en el sentido de que hay veces 
que tenemos sobre él alguna información, aunque incompleta; por ejemplo, si 
sabemos que el valor debe estar en un determinado intervalo, aunque no 
sepamos el valor exacto. Sin embargo, nosotros vamos a representar a todos por 
un mismo signo, ?, y no distinguiremos entre estos distintos niveles de conoci- 
miento. 


Ejemplos: 
En el ejemplo anterior, aunque sepamos que el empleado PEPE tiene menos de 


25 años, seguiremos representándolo por la misma tupla, <PEPE, ?), que si no 
supiéramos nada sobre su edad. 


Veamos otro ejemplo. Sea la relación PED(NA, NP, DA), donde hay una fila 
por pedido, NA representa el número del artículo pedido, NP el del proveedor y 
DA la descripción del artículo. Evidentemente, todas las filas que se refieran a 
pedidos del mismo artículo deberán tener la misma descripción DA. Supongamos 
que pedimos los artículos Al y A2, cuyas descripciones no conocemos, al pro- 
veedor Pl. Esto se reflejará insertando las tuplas <Al, Pl, 2, y <A2, Pl, >. 
Estos dos valores nulos representan valores desconocidos, pero que tienen que ser 
diferentes. Sin embargo, empleamos un único signo, ?, para ambos. 


El concepto de dominio debe ser revisado. Para los atributos que puedan 
tomar valor nulo, incluiremos en su dominio el signo ?. Puesto que el dominio 
es un conjunto, consideraremos el signo ? como un elemento más del conjunto, 
distinto a todos los demás. 


Una relación es un conjunto de tuplas. Por tanto, no puede haber tuplas 
duplicadas. Dadas dos tuplas, consideraremos que una es duplicada de la otra 
cuando todos los atributos que son nulos en una lo son también en la otra, y 
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todos los que no son nulos tienen en la otra el mismo valor. Así, la tupla <PEPE, 
2) y la <PEPE, 25) no son duplicadas y, por tanto, podrían coexistir en la 
relación EMPLEADOS. 


El concepto de superclave debe ser retocado. Diremos que un atributo A es 
una superclave cuando sus valores no nulos son todos distintos. Si A es compues- 
to, intrepretaremos que no es nulo cuando todos sus componentes no lo sean. 


Las operaciones con atributos deben ser revisadas para definir cómo operar 
con nulos. Así, se puede establecer la regla de que cualquier operación aritmética 
con un operando nulo dé resultado nulo. Esto es coherente con la interpretación 
de valor desconocido que hemos dado al nulo (el resultado de operar con un 
valor desconocido es desconocido). Las operaciones de comparación entre dos 
valores, que normalmente pueden dar resultado verdadero o falso, ahora podrán 
dar también desconocido o nulo, en caso de que alguno de los comparandos sea 
nulo. Por tanto, necesitaremos aplicar una lógica de tres valores (V, F, ?) en vez 
de la de dos valores, más sencilla e intuitiva. Esto se extiende a expresiones en 
que las comparaciones se combinan con operadores lógicos (A), (v), (7). Las 
tablas de resultados para estos operadores serán: 


0 A A 5 

E A A AO: Vi|F 
20, IRE: E EA 20 es 
F|F F PAUIV STE F |V 


Aunque la comparación de un valor cualquiera con otro nulo dé resultado 
nulo, para poder ordenar los elementos de un dominio es necesario establecer 
entre ellos un criterio bien definido de orden, incluyendo al nulo, ?. 


Hay que incluir también un nuevo predicado o condición que nos permita 
preguntar si el valor de un atributo es nulo. Lógicamente, sólo podrá dar como 
resultado V o F (no podrá dar nulo, ?; es decir, no puede ser desconocido saber 
si toma el valor desconocido). 


En cuanto a las operaciones del álgebra relacional, un ejemplo de las que 
habría que ampliar es la yunción. Si tomamos el criterio de considerar como 
iguales entre sí dos valores nulos, o un valor nulo y cualquier otro, obtenemos 
la yunción posibilista («may - be - join»). 


Ejemplo: 

R|AI|B S BC EYPS IA. RBA S ¿BE 
al EIA a 1 1 A 
brl2 Ye B a Í ? B 
Cc 2 b 2 2 ? 
ES 4 |C b 2 ? B 

Cc ? 1 A 
le ? ? B 
C le 2 ? 
c cd 4 Cc 
2 3 2 B 
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Es necesario definir una nueva operación de yunción natural, llamada 
yunción natural externa. Es como la yunción natural ya vista, pero añadiendo 
al resultado las tuplas de los operandos que, o bien tengan ? en el atributo 
común, o bien éste no exista en la otra relación. Estas tuplas añadidas se 
completan con ?. 


Yunción natural externa (YE): 


SMA RYES|A|B|C 
aló6 a al6 
cal [38 ¡YE E 
BS PASAS 
c|9 c|4]|9 
f ÍA di SOS 

Soap 17 
2 ES 
LAA 


(Obviamente: (R*S)<(R YES)). 


Equiyunción externa (con los mismos datos R y S anteriores): 


RYES(R.A=S.A) | RA | B 


DO 3:30 pPp 


2D DAO Op 
> OOIIDIIDIIA O 


2:10) :D)ULuwnN 


+ 3 CD 


Unión externa (suponemos que los atributos homónimos están definidos 
sobre el mismo dominio, y los heterónimos sobre dominios diferentes): 


Rol AEB | E S 1 BD 
al | bl | cl bl | di 
al bl cS b3 d2 
a2 b2 cl 
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En resumen, la inclusión de valores nulos exige una revisión y adaptación de 
las definiciones básicas y de las operaciones algébricas, según se ha expuesto. 


Nosotros admitiremos la posibilidad de valores nulos, pero sin revisar todos 
los aspectos que aquí se han indicado. Esto lo precisamos en el apartado 
siguiente. 


MODELO RELACIONAL DE DATOS 


Un modelo de datos es un sistema formal y abstracto que permite describir 
los datos de acuerdo con unas reglas y convenios predefinidos. Es formal en el 
sentido de que los objetos del sistema se manipulan siguiendo unas reglas perfec- 
tamente definidas, y utilizando exclusivamente los operadores definidos en el 
sistema, independientemente de lo que estos objetos y operadores puedan sig- 
nificar. 


Por el contrario, el modelo conceptual de datos, que como ya se ha dicho, 
es el conjunto de conceptos e interrelaciones que en la mente del analista forman 
una imagen del mundo real, no es un sistema formal. 


El modelo de datos es el lenguaje en el que el analista describe el modelo 
conceptual que su mente ha concebido, llamándose esta descripción, como ya se 
ha dicho, esquema conceptual. 


Un modelo de datos es tanto mejor cuanto más capacidad expresiva tenga 
para reproducir fielmente en el esquema conceptual el comportamiento del 
modelo conceptual, que a su vez debe ser imagen fiel del mundo real si está bien 
concebido. 


Un modelo de datos tiene tres componentes: 


1) Estructura de datos: Es una colección de objetos abstractos formados por 
datos. 


2) Operadores entre las estructuras: Conjunto de operadores, con reglas bien 
definidas, que permiten manipular las estructuras de datos. 


3) Definiciones de integridad: Colección de conceptos y reglas que permite 
expresar qué valores de datos pueden aparecer válidamente en nuestro 
esquema. 


Existen varios modelos de datos generalmente aceptados. Entre ellos los más 
utilizados son el jerárquico, el modelo en red y el relacional. Este último es el 
que aquí nos interesa. 


La definición del modelo relacional de datos generalmente aceptada en la 
literatura sobre el tema incluye la posibilidad de nulos, lo que lleva a redefinir 
los conceptos de clave, dominio, etc., en la forma en que se ha establecido en el 
apartado anterior. Sin embargo, no suelen incluirse en él las operaciones algébri- 
cas extendidas (por ejemplo, yunción externa y unión externa). Este será el 
modelo de datos al que nos referiremos de ahora en adelante. En resumen, tiene 
los componentes siguientes: 
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1) Estructura de datos: Dominios, relaciones, atributos, tuplas. 


2) Operadores: Los primitivos del álgebra relacional, es decir, unión, diferen- 
cia, producto cartesiano, proyección y selección. 


3) Definiciones de integridad: Los conceptos de claves y la posibilidad de 
valores nulos. 


También se incluyen aquí dos reglas de integridad, llamadas: 
a) Integridad de claves primarias. 


b) Integridad referencial. 


Ya se han comentado previamente todos estos componentes del modelo rela- 
cional de datos, excepto las reglas de integridad. Vamos a describirlas a conti- 
nuación. 


Integridad de claves primarias 


Al definir el concepto de claves se dijo que éstas pueden usarse como identi- 
ficadores de las tuplas de una relación, puesto que a cada valor de una clave 
corresponde una sola tupla y viceversa. 


En el modelo relacional, la única manera de encontrar una tupla determinada 
en una relación, es conociendo el valor de una clave. 


Una relación puede tener varias claves, pero suele aceptarse la conveniencia 
de emplear siempre la misma como identificador. A esta clave se la suele llamar 
clave primaria. Las restantes se llaman claves alternativas. 


Puesto que la clave primaria es el identificador designado para una relación, 
no debería de tomar valores nulos para evitar ambigijedades. Esta condición es 
la que hemos llamado regla de integridad de claves primarias (en la literatura se 
la suele llamar integridad de entidad). 


Con más precisión, la enunciamos así: ningún atributo de una clave primaria 
puede tomar valores nulos. 


Ejemplo: 


Veamos un caso de la ambigúedad que podría surgir si no se cumpliera esta regla. 
Consideremos la relación EMP (NE, ND, SUELDO), donde cada tupla represen- 
ta a un empleado de una empresa, NE es el número de un empleado, ND el de- 
partamento en que trabaja y SUELDO su sueldo. Tiene una sola clave: NE, que, 
por tanto, será la clave primaria. 


Si NE pudiera tomar valores nulos, podrían existir en EMP las tuplas: 
EMP (NE  ND SUELDO) 


El Dl 1000 
% Dl 1000 


La segunda tupla (en el orden en que se han escrito), se refiere a un empleado 
desconocido. ¿Tenemos, por tanto, un solo empleado o dos? Imposible saberlo 
con la información aportada por la relación solamente. 
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Podría pensarse que en el caso de tener varias claves, podríamos emplear 
como identificador unas veces a una y otras a otra, con lo que no tendríamos 
una única clave primaria, y ambas podrían tomar valores nulos. Esto no es así, 
y puede crear problemas de ambigúedad. 


Ejemplo: 

Sea la relación anterior, EMP, con un atributo más, NSS, que representa el 
número de afiliado a la Seguridad Social. La relación es por tanto: EMP (NE, 
NSS, ND, SUELDO). Tiene dos claves: NE y NSS. Supongamos que ambas 
pudieran tomar valores nulos (no simultáneamente). Podrían existir en EMP las 
tuplas: 


EMP (NE NSS ND SUELDO) 


Bl ? Dl 1000 
? SSI Dl 1000 


De nuevo es imposible contestar a la pregunta de si ambas tuplas representan al 
mismo empleado o no. 


En conclusión, en toda relación debe de designarse a una clave como 
primaria, y sus atributos no deben de tomar valores nulos. 


Si una relación tiene varias claves, cualquiera de ellas puede ser designada a 
priori como primaria. Para elegir la más conveniente, el diseñador de la Base de 
Datos deberá tener en cuenta el significado de la relación y sus atributos, y 
sopesar diversos factores. Pueden considerarse los siguientes: 


e Estabilidad. 
Considerar aquí si algunas claves son menos propensas a sufrir modifica- 
ciones en sus valores. 


e Facilidad de uso. 
Será, por ejemplo, más fácil de usar una clave numérica corta que otra 
alfanumérica con muchos caracteres. 


e Fiabilidad. 
Ver si alguna clave contiene digitos de validación u otros mecanismos de 
autodetección o corrección de errores. 


e Universalidad. 
Puede haber ciaves cuyo uso y conocimiento esté muy extendido (por 
ejemplo el número del Documento Nacional de Identidad). 


Integridad de referencia 


Es posible que unas relaciones hagan referencia a otras por medio de las 
claves primarias de éstas. Vamos a analizar esto más detalladamente. 


Ejemplo: 


Sean la relación EMP anterior, EMP (NE, NSS, ND, SUELDO), con clave pri- 
maria NE, y la DEP (ND, NOMBRE), donde cada tupla representa un departa- 
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mento de nombre NOMBRE, con clave primaria ND. NSS y NOMBRE son 
claves alternativas. Vemos que las tuplas de EMP hacen referencia a las de DEP 
por medio de la clave primaria de DEP, ND. Estas referencias entre relaciones 
suelen implicar condiciones de existencia. En nuestro ejemplo, no puede haber un 
empleado que trabaje en un departamento del que no tenemos información, lógi- 
camente. Dicho de otra forma, todo valor de ND en EMP debe existir en DEP. 
Cuando un atributo de una relación es clave de otra, y toma valores contenidos 
en ésta, se le suele llamar clave ajena. En nuestro ejemplo, ND es una clave ajena 
en EMP, y clave primaria en DEP. La regla de integridad referencial es que todo 
valor de la clave ajena debe de existir en una clave primaria. Enunciemos estas 
definiciones con más precisión. 


Se dice que un atributo, A, de una relación, R, es una clave ajena si se 
requiere que todos los valores de A no nulos existan en alguna clave primaria 
de alguna relación, no necesariamente distinta de R. Si A es un conjunto de 
atributos, A,, A»,..., A,, la definición anterior sigue siendo válida si se interpreta 
que A toma valor nulo cuando uno cualquiera de sus componentes sea nulo. 


Cuando en el esquema conceptual se designa a un atributo como clave ajena, 
conviene también especificar las acciones a tomar en caso de intentar actualizarlo 
con valores inválidos. Estas acciones dependerán del significado de los datos. 


Ejemplo: 


Así, en las actualizaciones de las relaciones anteriores, EMP (NE, NSS, ND, 
SUELDO) y DEP (ND, NOMBRE) pueden presentarse los siguientes casos. En 
cada uno de ellos se indican las posibles acciones, entre las que se debería elegir 
una, en función de cómo se asignen los empleados a los Departamentos. 


1) Inserción de una nueva tupla en DEP. No hay que comprobar nada. 


2) Borrado de una tupla de DEP. Hay que comprobar que el departamento que 
borramos no tiene empleados. Si así no fuere, la acción a tomar para mantener 
los datos en un estado válido de acuerdo con la integridad de referencia, podría 
ser una de las siguientes: 

a) Rechazar la petición de borrar la tupla de DEP. 


b) Aceptarla y propagarla a EMP. Es decir, borrar en EMP todas las tuplas 
que hagan referencia al departamento borrado. Este borrado podría propa- 
garse a su vez a otras relaciones que hagan referencia a EMP (propagación 
en cascada). 


c) Aceptarla y anular la referencia. Es decir, actualizar todas las tuplas 
de EMP que hagan referencia al departamento borrado poniendo nulo en 
el atributo EMP.ND. 


3) Actualización de una tupla de DEP modificando al atributo ND. Hay que com- 
probar que el departamento que modificamos no tiene empleados. Si así no 
fuere, la acción a tomar para mantener los datos en un estado válido de 
acuerdo con la integridad de referencia, podría ser una de las siguientes: 


a) Rechazar la petición de actualización. 


b) Aceptarla y propagarla a EMP. Es decir, actualizar en EMP todas las 
tuplas que hagan referencia al departamento modificado poniendo el nuevo 
valor en EMP.ND. 


c) Aceptarla y anular la referencia. Es decir, actualizar todas las tuplas 
de EMP que hagan referencia al departamento borrado poniendo nulo en 
el atributo EMP.ND. 
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4) Inserción de una nueva tupla en EMP. Hay que comprobar que el departa- 
mento de este nuevo empleado existe en DEP si no es nulo. Si así no fuere, 
se rechazará la petición de insertar la nueva tupla en EMP. 


5) Borrado de una tupla de EMP. No hay que comprobar nada. 


6) Actualización de una tupla de EMP modificando al atributo ND. Hay que 
comprobar que si el nuevo valor de EMP.ND no es nulo, existe en DEP. Si 
así no fuere, se rechazará la petición de actualización. 


EJERCICIOS PROPUESTOS 


1) Sean las relaciones R y S siguientes: 


22 


— 


R 


A|B SE: E 
ab ble 
e bid 
dle esla 


Hallar los resultados de las siguientes expresiones: 
1.1) RUS. 

1.2) RS. 

1.3) R+*S. 

1.4) PAIR). 

1.5) S(A=C)(R xS). 


Sean los esquemas de relación siguientes: 


a) 


b 


== 


== 


C 


d 


y 


e 


== 


HOMBRES (NOMH, EDAD) 
Clave: (NOMH) 


Significado: Cada fila representa un hombre, cuyo nombre es NOMH y su edad 
en años viene en EDAD. 


MUJERES (NOMM, EDAD) 
Clave: (NOMM) 


Significado: Cada fila representa una mujer, cuyo nombre es NOMM y su edad en 
años viene en EDAD. 


HSIM (NOMH, NOMM) 

Clave: (NOMH, NOMM) 

Significado: El hombre NOMH cae simpático a la mujer NOMM. 
MSIM (NOMH, NOMM) 

Clave: (NOMH, NOMM) 

Significado: La mujer NOMM cae simpática al hombre NOMH. 
MATRIM (NOMH, NOMM) 

Clave: (NOMH, NOMM) 

Significado: La pareja NOMH y NOMM están casados. 
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Escribir las sentencias necesarias para responder a las preguntas siguientes. 


2.1) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos. 


2.2) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos, con 
edades entre 20 y 30 años y que no estén casados entre sí. 


2.3) Hallar las parejas casadas cuyos componentes se caen mutuamente simpáticos. 
2.4) Hallar las mujeres casadas a quienes no cae simpático su marido. 

2.5) Hallar los hombres misóginos a quienes no cae simpática ninguna mujer. 

2.6) Hallar los hombres y mujeres asociales a quienes no cae nadie simpático. 

2.7) Hallar las mujeres casadas que caen simpáticas a algún hombre. 

2.8) Hallar los hombres a quienes sólo caen simpáticas mujeres casadas. 


3 


== 


Sean las relaciones siguientes: 


a) SOCIO (AFICIONADO, VIDEOCLUB) 
Significado: AFICIONADO es SOCIO de VIDEOCLUB. 
b) GUSTA (AFICIONADO, PELICULA) 
Significado: PELICULA de cine GUSTA a AFICIONADO. 
c) VIDEOTECA (VIDEOCLUB, PELICULA) 
Significado: VIDEOCLUB dispone en su VIDEOTECA de PELICULA. 


Escribir las sentencias necesarias para responder a las preguntas siguientes. 


3.1) Videoclubes que disponen de alguna película que le guste al aficionado José Pérez. 


3.2) Aficionados que son socios al menos de un videoclub que dispone de alguna 
película de su gusto. 


3.3) Aficionados que son socios solamente de videoclubes que disponen de alguna 
película de su gusto. 


3.4) Aficionados que no son socios de ningún videoclub donde tengan alguna película 
de su gusto. 


4 


pa 


Sean las tablas siguientes: 


a) PRO (NP, NOMP, CIUDADP) 
Clave: (NP) 


Significado: Cada fila representa un proveedor, cuyo identificador es NP, su nombre 
NOMP, y habita en la ciudad CIUDADP. 


b) ART (NA, DESA, COLOR, TALLA) 
Clave: (NA) 


Significado: Cada fila representa un artículo, cuyo identificador es NA y su descrip- 
ción DESA. 


FAB (NF, NOMF, CIUDADEF) 
Clave: (NF) 


Significado: Cada fila representa una fábrica, cuyo identificador es NF, su nombre 
NOME, y está situada en CIUDADF. 


Cc 


== 


42 / Algebra relacional 


2 


d) PED (NP, NA, NF, CANTIDAD) 
Clave: (NP, NA, NF) 


Significado: Cada fila representa un pedido del artículo NA, al proveedor NP, para 
la fábrica NF. 


Escribir las sentencias necesarias para responder a las preguntas siguientes: 


4.1) Hallar los identificadores de todas las fábricas. 

4.2) Hallar los nombres de las fábricas situadas en Madrid. 

4.3) Artículos tales que ningún otro tiene talla más pequeña. 

4.4) Proveedores que suministran a la fábrica Fl. 

4.5) Proveedores que suministran a la fábrica Fl el artículo Al. 
4.6) Nombres de las fábricas a las que suministra el proveedor Pl. 
4.7) Colores de los artículos suministrados por el proveedor Pl. 
4.8) Qué proveedores suministran a las fábricas Fl y F2. 

4.9) Proveedores que suministran artículos azules a la fábrica Fl. 
4.10) Artículos suministrados a las fábricas de Madrid. 


4.11) Proveedores que suministran algún artículo azul a las fábricas de Madrid o 
Lisboa. 


4.12) Artículos suministrados por proveedores en cuya ciudad hay alguna fábrica. 
4.13) Artículos suministrados a las fábricas de Madrid por proveedores de Madrid. 
4.14) Fábricas abastecidas por al menos un proveedor de distinta ciudad. 


4.15) Fábricas que no son abastecidas de artículos azules por proveedores de 
Madrid. 


4.16) Proveedores que suministran al menos un artículo suministrado por al menos 
otro proveedor que suministra al menos un artículo azul. 


4.17) Fábricas que usan al menos un artículo suministrado por el proveedor Pl. 


4.18) Parejas de ciudades tales que un proveedor de la primera abastece a una fábrica 
de la segunda. 


4.19) Obtener las tripletas de valores de (CIUDAD, NA, CIUDAD) tales que un 
proveedor de la primera ciudad abastece el artículo NA a una fábrica de la 
segunda ciudad. 


4.20) Repetir la pregunta anterior, pero sin obtener las tripletas en que ambas ciudades 
son la misma. 


4.21) Proveedores que suministran un mismo artículo, al menos, a todas las fábricas. 

4.22) Fábricas que tienen como único proveedor a Pl. 

4.23) Artículos que son suministrados a todas las fábricas de Madrid. 

4.24) Fábricas que usan, al menos, todos los artículos suministrados por el provee- 
dor Pl. 

4.25) Fábricas que usan sólo artículos que pueden ser suministrados por el Provee- 
dor Pl. 

4.26) Fábricas abastecidas por el proveedor P1 con todos los artículos que éste 
suministra. 

4.27) Fábricas que obtienen del proveedor Pl, total o parcialmente, todos los artículos 
que usan. 
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4.28) Fábricas abastecidas por todos los proveedores que suministran algún artículo 


de color azul. 


5) Sean las relaciones siguientes: 
a) EMPM (4E, 4D, NOME, CAT, SUELDO) 


b 


E 


d 


—= 


= 


pul 


Hay una tupla por cada empleado destinado en Madrid. 
AE: Número de empleado. 

4D: Número de departamento en el que trabaja. 
NOME: Nombre del empleado. 

CAT: Categoría del empleado. 

SUELDO: Sueldo del empleado. 

Clave primaria: 4E. 

EMPL (4E, 4D, NOME, CAT, SUELDO) 

Hay una tupla por cada empleado destinado en Lisboa. 
Iguales atributos que EMPM. 


Todos los empleados de la empresa están, o bien en EMPM, o bien en EMPL. Un 
empleado no puede estar a la vez en EMPM y EMPL. 


Clave primaria: AE. 
DEP (4D, NOMD, JEFE, ORG, LOCAL) 


Hay una tupla por cada departamento de la empresa, sea cual sea la ciudad donde 
se encuentre (Madrid o Lisboa). 


4D: Número de departamento. 
NOMD: Nombre del departamento. 
JEFE: Número de empleado del director del departamento. 


ORG: Número de departamento del que este departamento depende. Se supone 
que en el organigrama de la empresa, cada departamento depende de otro, y 
solamente de él, en una estructura jerárquica. Naturalmente habrá de existir un 
departamento origen, que no depende de ningúno. 


LOCAL: Dirección (es decir, ciudad, calle, número, planta) donde se encuentra 
ubicada la oficina del departamento. Algunos de estos locales son propiedad de la 
empresa y otros están alquilados. 


Claves: 4D, NOMD, JEFE. 
Clave primaria: 4D. 
ALQ (LOCAL, CANTIDAD) 


Hay una tupla por cada local alquilado. Cada local debe contener al menos un 
departamento. 


LOCAL: El mismo significado que en DEP. 
CANTIDAD: Coste del alquiler del local. 
Clave primaria: LOCAL. 


Preguntas: 


a) ¿Qué atributos no deben de tomar valores nulos de acuerdo con la regla de 


integridad de claves? (Integridad de Entidad). 


b) ¿Qué atributos son claves ajenas? (Integridad de Referencia). 
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Cálculo relacional 


INTRODUCCION INFORMAL AL CALCULO DE TUPLAS 


El cálculo relacional es un lenguaje basado en cálculo de predicados de 
primer orden (recuérdese que una relación expresa una propiedad o predicado), 
que es un intento de reproducir las leyes del razonamiento humano y, por tanto, 
de captar una parcela reducida del lenguaje natural. 


Es un lenguaje no procedimental («non procedural»). Es decir, se expresa en 
él lo que se quiere obtener, no cómo obtenerlo. 


Notación 
Conjunto de dominios: 
D=(D,: DS Di se, Da). 


Conjunto de todas las tuplas posibles que se pueden formar sobre D: TUP. 


Variables que representan tuplas de grado m, n, p, ... (puede omitirse el 
grado si está claramente implícito en el contexto): 


tm» Un» Vip» -** 

Estas variables toman valores en TUP o en subconjuntos de TUP. El 
conjunto de todos los valores posibles de una variable, t, lo representaremos por 
DOM(t). 

Mientras no se diga lo contrario, DOM(t) será el conjunto TUP. 


Para designar a los componentes de una tupla t emplearemos la notación: 
t(1), t(2), t8), ... 
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O también, a veces, si no se presta a confusión: 

O 

Relaciones definidas sobre D: letras mayúsculas superiores, como por ejemplo 
RES, Doe. 

Conjunto de todos los atributos de una relación dada: U. 


Atributos: Las letras mayúsculas inferiores suelen representar atributos sim- 
ples, por ejemplo A, B, C, ... Las últimas del alfabeto suelen representar 
atributos compuestos (conjuntos de atributos simples), por ejemplo X, Y, Z. Sin 
embargo, a veces, los atributos simples se representarán con un subíndice, como 
por ejemplo A,, A,, As, ..., utilizando en este caso cualquier letra sin subíndice 
para atributos compuestos. 


Condiciones de comparación 


Se construyen combinando variables y constantes con operadores de compa- 
ración y aritméticos. 
Comparan componentes de tuplas o tuplas enteras. Toman el valor de 
verdadero, falso o nulo, según sea el resultado de la comparación. 
Ejemplos: 
e Componentes de una misma tupla: (t, >t,). 
»* Componentes de distintas tuplas: (t, 7 =u;). 
e Constantes: (t,=8). 
e Con operación aritmética: (t, =t,+ub). 


Condiciones de pertenencia 


Se representan en la forma R(t). 


La condición R(t) toma el valor verdadero si la tupla t pertenece a la relación 
R, y falso en caso contrario. 


Condiciones compuestas 


Se construyen a partir de las anteriores combinándolas con operadores 
lógicos (A), (v) y (1). 
Ejemplos: 
(t, >t,) A (t, >8). 
(R(t) a (t, =8) 
(R(Y AGS(t) a (t, =8)) 
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Estas expresiones pueden ser V, F ó ?, según sean los valores de la tupla que 
sustituye a t (es decir, según el valor que tome la variable t). 


Cuantificador existencial 


Lo representaremos como: 3t (condición). 
Esto se lee: «Existe alguna tupla t que cumpla la condición.» 


La fórmula 
3t (condición) 


es verdadera si existe al menos un valor de la variable t que cumpla la condición, 
y es falsa en caso contrario. 


Ejemplos: 
1) La fórmula 
Jt(R (t)) 
es verdadera si R no está vacía. 
2) La fórmula 
Jt(R(t) A (t, =8)). 
es verdadera si alguna tupla de R empieza por 8. 


A veces, para simplificar la notación, restringiremos alguna variable a un 
determinado conjunto de valores. 


Ejemplo: 


Si restringimos la variable t al conjunto de las tuplas de R, es decir, si DOM(t)=R, 
la última fórmula anterior se escribiría: 


Jt(t, =8) 


Cuantificador universal 


Lo representaremos como: Vt (condición). 
Esto se lee: «Para todas las tuplas t se:cumple la condición.» 


La fórmula 
Vt (condición) 


es verdadera si para todos los valores de la variable t se cumple la condición, y 
falsa en caso contrario. 
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Ejemplos: 
La fórmula 

VH(ER(t) v ((R(0) y (t, =8))) 
es verdadera si todas las tuplas de R empiezan por 8. 
Restringiendo t sólo a R, la fórmula anterior se escribiría: 
Para DOM(t)=R: 

vt(t, =8) 


Expresiones 


Una expresión tiene la forma: 


(tn | F(0)) 


donde F es una fórmula. 


Significa: el conjunto de todas las tuplas t de grado n tales que la fórmula 
F(t) tome el valor verdadero. Puede omitirse el grado si está: claro en el contexto. 


La fórmula F(t) se construye combinando condiciones compuestas y cuantifi- 
cadores. 


Dentro de F(t), la única variable que puede estar no cuantificada es t. Es 
decir, podemos tener: 


(t]F(t, u, v, ...)) 


donde t es la única que puede estar no cuantificada; las otras, u, v, ..., están 
cuantificadas, es decir, aparecen con 3 0 Y. 


Ejemplos de expresiones: 
1) Formar una relación cogiendo la primera columna de R y la segunda de S: 
(tol INR At, =r JA 
3s(S(s) At,=s>) 
Si la variable r toma valores sólo en R y la s en S, la expresión anterior se 
escribiría: 
Para (DOM(r)=R) y (DOM(s)=S): 
(t 21 3r(t, =r,) 4 3s(t, =s>)) 
2) Formar una tupla de grado 1 con el mínimo valor del primer atributo de R: 
Para (DOM(r)=R) y (DOM(s)=R): 
(t 1 | 3r(t, =r,) AVs(t, < =s)) 
3) Extraer todas las tuplas de R si R está contenida en S. Si no, no extraer 
ninguna: 
Para (DOM(r)=R): 
(t| R(t) a Vr(S(r)) 
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4) Extraer todas las tuplas de R si hay alguna que empiece por 1 y otra que 
empiece por 2. Si no, no extraer ninguna: 
Para (DOM(r)=R) y (DOM(s)=R): 
(t] R(D) a 3r(r, =1) a 3s(s, =2)) 


Variables libres y ligadas 


En la escritura de fórmulas de cálculo se sigue el convenio de permitir que 
una misma variable pueda tomar valores diferentes, dentro de una misma 
fórmula. Cuando una variable está cuantificada, todas las ocurrencias de la 
misma que representan el mismo valor se llaman variables ligadas. Es un 
convenio análogo al uso de variables locales en programación modular. Las 
variables no ligadas se llaman libres. 


Ejemplos: 


Con este convenio, los ejemplos de expresiones del apartado anterior se podrían 
haber escrito así también: 


1) Para (DOM(r)=R): 


(variables 
ligadas) 


(t 2 | 3r(t, =r,) A 3r(t,=r>)) 


(variable libre) (variable libre) 
Se puede observar aquí que la variable r se usa dos veces, pudiendo tomar valores 


distintos cada vez. Es decir, posiblemente la tupla r que tiene t, =r, no es la misma 
tupla r que tiene t,=1). 


2) Para (DOM(r)=R): 
(ligadas) (ligadas) 


(ta | 3r(t, =r,) A (Vr(t, < =11))) 
(libre) ¡E (libre) 


3) 
(variables ligadas) 


(t]R() AVE R(t) v (R(D) A S(t))) 
(libre) 
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4) (libre) (ligadas) 


(| RE) NAJUROO » (t,=1) 
ARO n (t, =2))) 


(ligadas) 


Resumiendo, en toda fórmula F puede haber varias ocurrencias de una 
variable x. Cada ocurrencia puede ser libre o ligada, de forma que podemos 
clasificar sus ocurrencias en varios grupos: 

e El grupo de ocurrencias libres. 

e El primer grupo de ocurrencias ligadas entre sí. 

e El segundo grupo de ocurrencias ligadas entre sí. 

o Etc. 


Podríamos tener, por ejemplo, una situación como la indicada en la siguiente 
figura: 


(libres) 
OCA | TEO NE | A A J bar | A x) 
pd lis Pd 
(ligadas (1) (ligadas (2)) 


Todas las ocurrencias de un grupo se reemplazan por la misma tupla cuando 
se quiere comprobar si una tupla verifica .o no la fórmula F. En cambio, 
ocurrencias de distintos grupos pueden reemplazarse por diferentes tuplas. 


Solamente puede haber un grupo de variables libres en F, y debe correspon- 
der con la variable inicial, t, de la expresión 


(t|F(t;...)) 


Las ocurrencias de variables en condiciones de comparación o de pertenencia 
son libres en principio. 


Las ocurrencias en expresiones formadas combinando condiciones con A, v 
y — también son libres. 


Las ocurrencias con cuantificadores son ligadas. 


Asi, si en F(t, u, v, ...) todas las ocurrencias de t, u, v, ..., son libres, al 
formar 


Jt(F(t, u, v, ...)), o 
Vt(E(t, u, v, ...)), 


se ligan todas las ocurrencias de t entre sí. 
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Si en F(t, u, v, ...), t tiene ocurrencias libres y ligadas, en 


t(F(t, u, v, ...)), o en 
JE BNE, Ue YD): 


todas las ocurrencias libres de t en F pasan a estar ligadas entre sí y con la 
ocurrencia de t que sigue al cuantificador. 


CALCULO RESTRINGIDO DE TUPLAS 
Con las definiciones dadas hasta aquí, sería válido escribir la sentencia 


Esto expresa el conjunto de todas las tuplas de grado r pertenecientes al 
conjunto TUP que no están en R(t). Este conjunto puede ser infinito, por lo que 
puede ser imposible evaluar esta expresión. 


Denominaremos fórmulas sanas a las que pueden evaluarse con un proceso 
o algoritmo finito. 


Las fórmulas insanas pueden transformarse en otras sanas (no equivalentes) 
restringiendo los dominios de variación de algunas de sus variables a subconjun- 
tos finitos de TUP. 


Ejemplo: 
Tomemos la fórmula insana anterior: 

(t. 1 R(t) 
(Todas las tuplas de grado r de TUP que no están en R(t)). 
Podemos transformarla en la siguiente fórmula sana (no equivalente): 
Para DOM(t)=S: 

(t| 3R(t) 
(Significado: Todas las tuplas de S que no están en R). 


Tal como se definió previamente el álgebra, no se presentan en ella estos 
problemas. Puesto que los operandos de las expresiones algebraicas son finitos 
siempre (constantes o relaciones), los resultados de aplicarles los operadores 
primitivos también lo serán (recuérdese que en álgebra no se incluyó la operación 
de complementar). Dicho de otra forma, todas las expresiones algebraicas son 
sanas. Por tanto, toda expresión de cálculo equivalente a otra de álgebra, se 
podrá evaluar en un proceso finito, es decir, es sana. 


Denominaremos cálculo restringido de tuplas a todas las expresiones de 
cálculo de tuplas que tienen alguna expresión algebraica equivalente. Según esta 
definición, todas las expresiones del cálculo restringido son sanas, y además, el 
álgebra es tan expresiva como el cálculo restringido. Recíprocamente, toda 
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expresión de álgebra puede expresarse en cálculo restringido, como veremos en 
el apartado siguiente, por lo que ambos son equipotentes. 


POTENCIA EXPRESIVA DEL CALCULO 
RESTRINGIDO DE TUPLAS 


Para toda expresión algebraica existe una fórmula de cálculo equivalente, por 
lo que el cálculo restringido y el álgebra tienen la misma potencia expresiva. 


Veamos cómo expresar los operadores primitivos del álgebra en fórmulas de 
cálculo. 


1) Unión. 
Sea E=RuS. Podemos expresar E en cálculo como sigue: 
E=(t|R(t) v S(t)) 


2) Diferencia. 
E=R-—S 
E=(t|R(t) a (7S(t) 


3) Producto cartesiano. 
E=RxS 
Para R de grado r, S de grado s, DOM(u)=R y DOM(v)=S: 
E= (ti +, | (3u) Ev) 
((t, =u;,) A (t, =u)) A ...(t,=U,) 
Altr+1 =V1) A (t,+2=V2) A ...(t, + ,=V5))) 
4) Proyección. 
E=P(A,, A,, Az, ...) (R) 
E=(t|3u(R(u) y (t, =4,) A(t,=u>) A...) 
5) Selección. 
E=S(F) (R) 
E=(t|R(t) A (P)) 
Por ejemplo 
(Sít, =1,) (R))=(t]R(t) an (t, =1t,)) 


Como ejemplo, y para completar la lista anterior, veamos las operaciones de 
intersección y cociente: 


El =(R NS) 
El =(t|R(t) AS(t) 
E2 =(R qm +1/S(n) 
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Para DOM(r)=R y DOM(s)=S: 

E2= (ty | VS (Fr((r(1)=t(1)) A 
(r(2)=t(Q2) »...(r(m)=t(m)) A 
(r(m+1)=s(1)) 1 (r(m+2)=s(2))...A 
(r(m +n)=s(n)) 


Si consideramos una expresión algebraica, E, sin operadores, sólo puede 
tratarse de una relación constante o variable. En ambos casos es expresable en 
cálculo. Como cualquier expresión algebraica se puede construir recurrentemente 
a partir de constantes y variables combinadas con operadores primitivos, se 
deduce que es expresable en cálculo. 


LENGUAJES PROCEDIMENTALES («PROCEDURAL») 


El álgebra es un lenguaje procedimental. Esto significa que para indicar el 
resultado que queremos obtener, enunciamos cómo obtenerlo. Es decir, qué 
operaciones y en qué secuencia hay que realizarlas para llegar al resultado 
deseado. 


El cálculo no es procedimental. En cálculo se indica directamente qué 
resultados deseamos, sin indicar cómo llegar a él. 


Parece, por tanto, en principio, que el cálculo será un lenguaje preferible al 
álgebra, puesto que el usuario sólo tiene que definir el resultado final que desea 
obtener, siendo responsabilidad del sistema gestor de la base de datos (SGBD) 
la definición de la secuencia de operaciones elementales necesarias para evaluar 
la petición. 


Sin embargo, como ambos lenguajes son equipotentes, esta discusión es 
irrelevante, puesto que el SGBD puede transformar una sentencia expresada en 
uno de ellos al otro. Por otra parte, cuando el usuario expresa una petición, 
tanto en álgebra como en cálculo, el SGBD deberá hallar el procedimiento 
óptimo para responderla. Esto hace que, en la práctica, aunque el usuario se 
exprese en álgebra, la secuencia de procesos pueda ser diferente a la indicada en 
la petición, por lo que, de hecho, el álgebra es procedimental cara al usuario, 
pero no dentro del sistema. 


En definitiva, también el álgebra es, desde este punto de vista, simplemente 
un medio de expresar lo que se quiere conseguir, y no el cómo conseguirlo (se 
expresa el qué mediante el cómo). 


Desde un punto de vista psicológico, se ha detectado en algunas experiencias 
que el uso de un lenguaje procedimental puede ser más sencillo, pues permite 
descomponer una petición en varios pasos más fácilmente que un lenguaje no 
procedimental. De todas formas, esto no parece concluyente, pues depende de 
las características psicológicas de cada persona. 


En definitiva, la discusión comparativa entre los méritos de los lenguajes del 
tipo álgebra o del tipo cálculo es irrelevante desde el punto de vista del SGBD. 
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Algunas consultas son más fácilmente expresables en cálculo que en álgebra, 
y otras al revés. 


Ejemplos: 
1) Hallar el valor mínimo del primer atributo de R. 
Cálculo: 
Para DOM(r)=R y DOM(s)=R, 
(t (| 3r(t, =r,) AVs(t, <=s,)) 
Algebra: 


Sean Ay, A), ..., los atributos de R. Sea T una relación igual a la R, con 
atributos B,, B,, ... Es decir, que P(A,) (R)=P(B,) (T). El valor mínimo de 
A, viene dado por: 


[S(A, <=B,) ((P(A,) RI(PB,) (T))] 
(P(A,) (R)) 


Sean R(A, B) y S(B, C) dos relaciones binarias con atributos A, B y C. Se 
llama composición de estas relaciones en teoría de conjuntos a la relación 
binaria obtenida al concatenar todos los valores de A que se corresponden con 
los de C a través de valores comunes de B. Hallemos esta relación en álgebra y 
cálculo. 


ho 


Cálculo: 
(En Es) RIODAS(s)A 
(1,=8,) A(t, =r,) A(t,=8),))) 
Algebra: 
P(A, C) (R*S) 


LENGUAJES RELACIONALMENTE COMPLETOS 


Tanto el álgebra como el cálculo restringido de tuplas (y el de dominios, que 
mencionaremos más adelante), son equipotentes. Es decir, cualquier consulta 
expresada en uno de ellos puede expresarse en los otros. 


Parece natural entonces considerar a estos lenguajes como patrón o medida 
para estudiar la potencia expresiva de otros. 


Se dice que un lenguaje es relacionalmente completo si tiene, al menos, la 
potencia expresiva del álgebra relacional. Es decir, si para toda expresión de 
álgebra existe alguna sentencia equivalente en ese lenguaje. 


Dicho de otra forma, el álgebra y el cálculo relacionales son lenguajes 
relacionalmente completos. Esto no quiere decir que nos permitan expresar 
cualquier tipo de consulta imaginable. 


En álgebra no existen bucles iterativos ni manipulaciones aritméticas. Tam- 
poco existe el concepto de orden o clasificación entre las tuplas de una relación 
resultante de otras. 


54 / Cálculo relacional 


S 


DEFINICION FORMALIZADA DEL CALCULO DE TUPLAS 


e Las expresiones son de la forma tn 1 F(0), donde t es una variable sobre 
las tuplas de TUP de grado n y F es una fórmula. 


e F(t) es una fórmula construida con átomos y operadores. Los átomos 
pueden ser de la forma: 


1) (R(s)), donde R es una relación y s una variable. 


2) (s(i)Cu (3)), donde s y u son variables, C es un operador de comparación, 


1 y j son identificadores de componentes de las tuplas s y u. 
3) (s(i)Ca) o (aCs(i)), donde s, i y C son como antes, y a es una constante. 


e Todo átomo es una fórmula. En ella todas las ocurrencias de variables 
son libres. 


e Si Fl y F2 son fórmulas, también lo son (F1 1 F2), (Fl vF2), (A Fl). 
En estas últimas, las ocurrencias de variables son libres o ligadas, según 
lo sean en Fl o en F2. 


e Si F es una fórmula, también lo es Agea Las ocurrencias de s que 
sean libres en F, están ligadas en (3s(F)) a la s que sigue al cuantificador 
3. Otras ocurrencias de variables en F son ligadas o libres en (3s(F)) según 
sean en F. 


e Si F es una fórmula, también lo es (Vs(F)). Las ocurrencias libres y 
ligadas se definen como en el caso anterior. 


e Pueden usarse paréntesis. 
e Ninguna otra cosa es una fórmula. 


e En una expresión (t|F(t)), sólo t puede tener ocurrencias libres en la 
fórmula F. 


INTRODUCCION INFORMAL AL CALCULO DE DOMINIOS 


Se define igual que el cálculo de tuplas, pero manejando variables cuyos 
campos de valores posibles son los elementos de los dominios. 
Ejemplos: 


1) Extraer todas las tuplas de una relación binaria R, si R contiene dos o más 
tuplas. Si no, no extraer ninguna. 


Cálculo de tuplas: 
(to IURO ARO) a ((t17 =u,) v (t2 7 =u2))) 

Cálculo de dominios (x, y, z, w, son variables de dominio): 
(xy |(Ez) w) (RGy) AR (2w) a (67 =2) v (y =w)) 


2) Extraer todas las tuplas de R, que empiecen por 1 si hay alguna que empiece 
por 2. Si no, no extraer ninguna. 
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Cálculo de tuplas: 

(to 1R(YA(t,=1) AGU(R(y) a (u, =2)))) 
Cálculo de dominios: 

(xy |R(xy) A(x=1) , z(Ew(R (2w))) a (2=2)))) 


Extraer todas las tuplas de R, que empiecen por 1 si no hay ninguna que 
empiece por 2. Si no, no extraer ninguna. 


3 


pa 


Cálculo de tuplas: 
Para DOM(s)=R: 
(t]R() a(t,=1) A (vs(s, 7 =2)) 
Cálculo de dominios: 
Para DOM(2z)=(dominio del segundo atributo de R): 
(y IRGy)A(=1) A (WAR (2))) 
O también: 
(xy |R(xy) A (x=1) 1 73z(R (22))) 
En el cálculo de dominios hay que indicar sobre qué dominio toma valores 
cada variable si no se deduce claramente del contexto. 


El cálculo de dominios restringido se define análogamente al de tuplas, y es 
equipotente con él y con el álgebra. 


EJERCICIOS PROPUESTOS 
1) Responder en cálculo a las preguntas del ejercicio 2 del capítulo anterior. 
2) Responder en cálculo a las preguntas del ejercicio 3 del capítulo anterior. 


3) Responder en cálculo a las preguntas del ejercicio 4 del capítulo anterior. 
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CONDICIONES DE INTEGRIDAD 


Sea B un esquema de base de datos, es decir, un conjunto de esquemas de 
relaciones, B=(R,, R,, Ra, ..., R.). 


El contenido de esta base de datos varía con el tiempo mediante borrado, 
añadido o modificación de sus tuplas. 


De acuerdo con el significado de las relaciones de B, no todas las tuplas 
posibles construidas sobre los dominios de un esquema de relación R; pueden 
estar incluidas en una extensión de R¡. Normalmente, sólo las tuplas que 
cumplan ciertas condiciones o propiedades, podrán ser elementos válidos de R,, 
según lo que R, signifique. 


Llamaremos CINT al conjunto de las condiciones que deben cumplir las 
tuplas de B a lo largo del tiempo, en función del significado de los distintos 
esquemas de relación de B. Estas condiciones se llaman condiciones de integri- 
dad, y en ellas se reflejan propiedades que son invariantes al transcurrir el 
tiempo. (En la fugacidad de este mundo pocas cosas hay eternas, incluyendo las 
condiciones de integridad. Al decir invariantes con el tiempo nos referimos a un 
lapso de tiempo arbitrariamente largo, de acuerdo con las necesidades de uso de 
los datos.) 


Las condiciones de CINT pueden referirse a tuplas o atributos de una 
relación (condiciones intrarrelación) o de varias (condiciones interrelaciones). 
Expresan restricciones semánticas, es decir, dependen del significado de las 
relaciones y sus atributos. 


Podemos distinguir dos tipos de condiciones de integridad: 


1) Condiciones de estado: Para comprobar si una extensión determinada 
las verifica (o sea, si es un estado válido), basta mirar el contenido de 
una, varias O todas las relaciones del esquema. Es decir, que basta 
tener en cuenta las extensiones actuales de una o varias relaciones del 
esquema para saber si es un estado válido o no. 
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2) Condiciones de transición: Enuncian si, a partir de un estado válido, 
el obtenido aplicando un cierto cambio (insertar, actualizar o borrar 
n tuplas) es también válido o no. Es decir, para saber si el nuevo 
estado es válido, hace falta información sobre las extensiones actuales 
y las previas (por ejemplo si ha de cumplirse que toda actualización 
de una cierta fecha ha de ser con un valor posterior al que sustituye). 


Aunque las condiciones de integridad son consecuencia del significado de los 
datos, se expresan en función de los valores de éstos exclusivamente, por lo que, 
para comprobar si se cumplen, no es necesario conocer el significado de los 
datos, sino que basta con mirar el contenido de las relaciones (actual o pasado). 


Ejemplo: 
Sea el esquema: 
PED (NUMPEDIDO, NUMPROVEEDOR) 
LIPE (NUMLINEA, NUMPEDIDO, NUMARTICULO, CANTIDAD) 


En este esquema, cada tupla de PED representa un pedido. Por tanto, para saber 
si es válido insertar la tupla (100, 1000), un criterio es si existe un pedido de 
número 100 al proveedor 1000. Si es así, hay que incluir esta tupla en PED, y en 
caso contrario, no. Evidentemente, este criterio de validez para la operación de 
insertar es ajeno al contenido actual o pasado de PED, por lo que no es una 
condición de integridad. 


Sí sería en cambio una condición de integridad la siguiente: todo valor de 
NUMPEDIDO en LIPE debe existir en NUMPEDIDO de PED. Para compro- 
bar si esta condición se cumple o no, basta considerar los valores contenidos en 
PED y LIPE, independientemente de qué representan estas relaciones. 


Ejemplos de condiciones de integridad 
1) Para toda tupla de un esquema de relación dado, el valor de un atributo debe 
ser inferior a otro. Ejemplo: 
EMP(NRO, FECHANAC, FECHAINGRESO) 


Evidentemente, para todo empleado la fecha de nacimiento deberá ser anterior 
a la de su ingreso en la empresa. Esta condición se podría expresar en cálculo: 


Para DOM(t) =EMP: 
Vt((FECHANAC<FECHAINGRESO) 

2) Para un esquema de relación dado, R, los valores de un conjunto, Á, de sus 
atributos no pueden repetirse (es decir, que A es una superclave de R). 
En cálculo: 
Para DOM(t)=R, DOM(u)=R: 

(vt) (Vu) (((=u) v (t(AJ] =u(A)) 
Para dos esquemas de relación dados, R y S, el valor mínimo de un cierto 


atributo B, de S, debe ser siempre mayor que el mínimo de otro atributo, A, 
de R. 


¡09 
— 
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En cálculo: 

Para DOM(t)=R, DOM(u)=S: 
(At(Vu(t(A) < =u(B)))) 

Ejemplo: 


COCHES (MARCA, MODELO, FECHALANZAMIENTO) 
EMP-COCHE (NROEMP, FECHACOMPRA) 


Evidentemente, ningún empleado puede comprar un coche antes de que haya 
alguno disponible en el mercado. Es decir, el mínimo valor de FECHACOM- 
PRA debe ser mayor que el mínimo de FECHALANZAMIENTO. 


4 


— 


Para dos esquemas dados, todo valor de un atributo, A, de uno de ellos, debe 
existir en el atributo B del otro. 


En cálculo: 

Para DOM(t)=R, DOM(u)=S: 
(vt(Ju(t(A) =u(B))) 

Ejemplo: 


ARTICULO (NUMART, DESCRIPCION) 
PEDIDO (NUMART, PROVEEDOR, CANTIDAD) 


Todo artículo pedido (atributo PEDIDO.NUMART) debe existir en la tabla 
de artículos (atributo ARTICULO.NUMART). 


Consecuencia: no se puede insertar una nueva fila en la tabla PEDIDO si no 
existe previamente una fila en la tabla ARTICULO con el mismo valor de 
NUMART; no se puede borrar una fila de ARTICULO si hay pedidos de él 
en PEDIDO. 


DISEÑOS EQUIVALENTES 


Dado un esquema de base de datos B, se puede plantear la pregunta de si 
es posible encontrar otro, B', equivalente a él y cuál de ellos es preferible. 


El nuevo diseño, B', deberá contener al menos la misma información que el 
viejo, B. 

Diremos que B' contiene al menos tanta información como B, si existe un 
algoritmo que nos permite obtener una extensión cualquiera de B a partir de 
una de B'. 

Ejemplo 1: 
B: 
PED (ART, PROVD, CANT, PRECIO) 
PB: 
PED (ART, PROVD, CANT) 
INVENTARIO (ART, PRECIO, CANTIDAD) 
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Algoritmo (expresado en álgebra) para hallar PED de B en función de las 
relaciones de B”: 


(B.PED) =P(ART,PROVD,CANT,PRECIO) ((B'.PED) * (B'.INVENTARIO)) 
En este ejemplo, B', contiene más información que B: 


e Hay atributos en B' que no están en B (el atributo CANTIDAD, que expresa 
la cantidad que hay en existencias en almacén de un determinado artículo). 


e Puede haber tuplas en B' que no puedan existir en B. Por ejemplo, en 
INVENTARIO puede haber artículos que no estén pedidos, y que por tanto 
no figurarán en PED. 


Ejemplo 2: 
B: 
COCHES (MARCA, MODELO, FECHALANZ) 
B': 
COCHESMODERNOS (MARCA, MODELO, FECHALANZ) 
COCHESVIEJOS (MARCA, MODELO, FECHALANZ) 
Algoritmo (expresado en álgebra): 


COCHESMODERNOS=S (FECHALANZ > =1980) (COCHES) 
COCHESVIEJOS=S (FECHALANZ)< 1980) (COCHES) 
(COCHES) =(COCHESMODERNOS) u (COCHESVIEJOS) 


Evidentemente, B' y B contienen la misma información. 


Para decidir si es preferible el esquema o diseño representado por B' o por 
B, hay que tener en cuenta las condiciones de integridad. Es posible que las 
condiciones CINT aplicables a B, no lo sean a B'. En general, las condiciones 
CINT aplicables a B se tranformarán en otras distintas CINT' aplicables a B'. 


Veamos esto en los ejemplos siguientes. 


Ejemplo 3: 

En el ejemplo 1 anterior teníamos las siguientes condiciones de integridad: 
CINT: 

A cada artículo corresponde un precio. Para DOM(t)=PED, DOM(u)=PED: 
(vt) (Vu) (t(ART)A =u(ART)) v ((t(ART)=u(ART) » (t(PRECIO)=u(PRECIO)) 

Además, (ART,PROVD) es una superclave (es decir, toma valores no repetidos). 
CINT": 


Para toda fila de PED debe existir una en INVENTARIO con el mismo número 
de artículo. Es decir: 


Para DOM(t)=B'".PED, DOM(u)=INVENTARIO: 
(VtGu(t(ART)=u(ART))) 
Además, ART es superclave de INVENTARIO, y (ART,PROVD) de PED. 
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Ejemplo 4: 
En el ejemplo 2 anterior tenemos las condiciones siguientes: 


CINT: No hay restricciones (CINT= 0D). 
CINT*: 


Para toda fila de COCHESMODERNOS, debe ser la fecha de lanzamiento 
posterior a 1980. Para las filas de COCHESVIEJOS deberá ser anterior. 
En cálculo para DOM(t)=COCHESMODERNOS y DOM(u)=COCHES- 
VIEJOS: 

(vt(t(FECHALANZ)> = 1980), 

(Vu(u(FECHALANZ)< 1980)) 


En definitiva, dados dos esquemas de diseño, (B, CINT) y (B', CINT>), tales 
que B' contenga al menos tanta información como B, debemos decidir cuál es 
preferible. Esto depende, entre otras cosas, del uso que se haga de la información. 
Si predominan las actualizaciones sobre las extracciones de datos (consultas), 
será más eficiente el esquema cuyas condiciones de integridad sean más fácilmen- 
te verificables (menos accesos a disco, por ejemplo) en el momento de actualizar- 
lo (o sea, al añadir, borrar o modificar alguna tupla). Así, en el ejemplo 4 
anterior teníamos (CINT= ([)), por lo que se puede actualizar el esquema B sin 
ninguna restricción, al contrario que el B', donde hay que comprobar cada vez 
que se actualice si las condiciones CINT' se cumplen. Por el contrario, para 
consultas por fecha sería más eficiente, en principio, el esquema B' (menos tuplas 
que investigar). 


REVERSIBILIDAD POR YUNCION 


Si descomponemos un esquema R en otros mediante proyecciones, ¿se 
obtiene un diseño equivalente? Analicemos esta cuestión. 

Dado un esquema de relación, R, no siempre es posible descomponerlo en 
otros mediante proyecciones de manera que al ayuntar éstos, se reproduzca R. 
En caso de serlo, decimos que esta descomposición de R es reversible por 
yunción («lossless join decomposition»). 


Ante todo precisemos la forma de descomponer. Supongamos que descompo- 
nemos el esquema R mediante dos proyecciones en S y T. Sea U el conjunto de 
todos los atributos de R, y sean A, B y C subconjuntos propios de U disjuntos 
y que cubren totalmente a U. Es decir: 


A2=0; B2=(0; C1=0; 
AnB=0; AnC=0Q; BAC=0); 
AcU; BcU; CU; 
AuBuc=U 


Entonces, proyectamos R de la forma siguiente: 


S=P(A, B) (R); 
T=P(A, C) (R); 
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Vamos a analizar si esta descomposición es reversible, es decir, si R=S+*T. 


Sea <a, b, c> una tupla cualquiera de R(A, B, C). Entonces, <a, b> estará 
en S y <a, c> estará en T. Por tanto, <a, b, c> estará en la yunción de S y T 
Es decir, R está contenida en la yunción de S y T: 


R<(S*T) 


En general, al ayuntar S y T, se obtienen todas las tuplas de R y algunas 
más que no están en R. 


En efecto, si <a, b, c> no está en R, pero si están en R <a, b, d> y <a, e, Cc», 
tendremos que como <a, b> está en S y <a, c>» en T, <a, b, c> estará en la 
yunción de S y T. Es decir, en la yunción de S y T aparece la tupla <a, b, c> 
que no está en R. Por tanto, en general, (R<(S* T)). Veamos qué condiciones 
debe cumplir R para que sea (R=(S * T)): 


La condición necesaria y suficiente para que la descomposición anterior sea reversi- 
¡| ) ble por yunción es que si existen dos tuplas en R con el mismo valor en A, también 
7 >) existan las que resulten de intercambiar entre ellas los valores de B. 


Ejemplo 1: 


Si A es una superclave de R (o sea, toma valores únicos en R), se cumple la 
condición anterior, y por tanto la descomposición es reversible: 


S|AÍ|B 1 E 
a |m a 1 
b|m DAA 
en (0 1 
d|m d 2 


Ejemplo 2: 


Si en las tuplas donde se repite A, también se repite B, también se cumple la 
condición anterior, y por tanto la descomposición es reversible. Este tipo de 
condición es muy importante, y recibe un nombre específico: se dice que B depende 
funcionalmente de A, y se representa (A>B). También diremos que «A define 
funcionalmente a B»: 


R SOMA. IB 
a|m 
bn 
crm 


Vemos que R=(S * T). 
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Ejemplo 3: 4 
Un ejemplo en el caso general: 


Ra] A UB" 14€ S|AJ]|B PA E 
ar |“ me-] am. Sl all 
at m«2 a|n o A 
a [anal b|m D ¿13 
A EP 00 b|n » 
Ss bm |-3 
- Dis 


Vemos aquí que en todas las tuplas en que se repite A, intercambiando los valores 
de B, se obtienen otras tuplas que también están en R. Este tipo de condición 
también tiene la importancia suficiente como para designarla con un nombre 
específico: se dice que hay una dependencia plural entre A y B, o también que B 
depende pluralmente de Á, o que A pluridefine a B, y se representa (A—»B). 


En definitiva, la condición necesaria y suficiente para que la descomposición 
sea reversible se representa en general como (AB). 


Por otra parte, también hemos visto que si se verifica que (A > B) también 
se verifica (AB). 


Además, como A, B y C son disjuntos y cubren totalmente a U, la condición 
(A>B) es equivalente a (A>C). En efecto, por simetría, lo mismo da decir que 
al repetirse Á se obtienen tuplas de R si se intercambian los valores de B que si 
se intercambian los valores de C. 


Vamos a ver que (A>B) es condición necesaria y suficiente para que la 
descomposición sea reversible. Veamos primero que es suficiente, porque si se 
cumple, la descomposición es reversible. En efecto, supongamos que tomamos 
dos tuplas que empiecen por a en S y T. Por ejemplo: <aA> en S y <al> en T. 
Al ayuntar S y T se obtiene que <aA1> está en (S* T). Por otra parte, el hecho 
de que <aA)> esté en S, quiere decir que hay en R una tupla de la forma <aAx>. 
Análogamente, por estar (al) en T, en R existe una tupla de la forma (a y 1>. 
Intercambiando entre ellas los valores de B, obtendremos las tuplas <a y x> y 
<(aA1), que también existirán en R. Es decir, si se cumple la condición (A—»B), 
toda tupla de (S * T) está en R. Por tanto, la descomposición es reversible. 


Veamos ahora el reciproco: que si la descomposición es reversible, se cumple 
(A>B). 


En efecto, supongamos que la descomposición es reversible. Esto quiere decir 
que toda tupla de (S * T) está en R. 


Supongamos que tomamos dos tuplas de S y T que empiecen por a, tales como 
<aA> de S y <al> de T. Esto quiere decir que existen en R dos tuplas de la forma 
<(aAx> y <a y 1). Pero esto implica también que <ay> está en S y (ax> en T. 
Por tanto, (S * T) contiene las tuplas <XaA1), <aAx), <a y 1) y <a y x». Como la 
descomposición es reversible, estas tuplas también están en R. Luego se cumple 
(A>B). 
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La definición dada para la condición A>»B es extensible y válida para el caso 
en que A y B no sean disjuntos. Así lo supondremos de ahora en adelante 
mientras no se diga lo contrario. 


En definitiva, supongamos que tenemos un esquema de diseño,(B, CINT), 
formado por un esquema de base de datos, B, y un conjunto de condiciones de 
integridad, CINT, donde B contiene un solo esquema de relación, R, y CINT 
una sola condición expresada por (A>»B), donde A y B son subconjuntos de U 
(los atributos de R) propios y disjuntos. Como (A>»B), podemos descomponer 
R en (S=P(A, B) (A) y T=P(A, C) (R)) de forma reversible por yunción, como 
ya hemos visto. Supongamos entonces que reemplazamos el esquema de diseño 
de partida (B, CINT) por otro (B', CINT, donde B'=(S, T). Veamos si este 
nuevo esquema de diseño reemplaza válidamente al primero. 


Evidentemente, cualesquiera que sean las tuplas de S y T, se puede recompo- 
ner un estado válido de R. Por tanto, (CINT'=([/) (no hay condiciones). Esto 
quiere decir que el nuevo esquema es más fácil de actualizar que el original. 


Por otra parte, el nuevo esquema de diseño puede contener más información 
que el original, pues si incluimos en S una tupla que empiece por un valor de 
A que no exista en T, esta tupla no se reflejará en R. 


Ejemplo: 


T|A E 


T 
wW>>»|u 
Tp p 

w 


(La tupla <cB> de S no aparece en la yunción.) 


En resumen, el nuevo esquema de diseño es válido, pues contiene toda la 
información del original (contiene más), y es más sencillo de mantener, pues no 
es necesario comprobar nada al actualizar tuplas. Cualquier tupla es válida en 
S y T. Los esquemas son: 

e Primer esquema de diseño: 

B=(R); CINT=(A>B); 
e Segundo esquema de diseño: 
B'=(S, T); CINT'=(); 
donde S=P(A, B) (R), y T=P(A, C) (R). 
e Algoritmo para reconstruir una extensión de B a partir de B': 
R=(Sx*T) 


Supongamos ahora que CINT en vez de contener una sola condición, (A—>»B), 
contiene varias, y además de cualquier tipo (dependencias plurales, dependencias 
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funcionales, condiciones aritméticas, etc.). Ahora ya CINT' no sería probable- 
mente vacío, y habría que analizar la validez del esquema B' obtenido mediante 
las proyecciones de R. 


Para estudiar este problema, vamos a simplificarlo restringiendo en principio 
las condiciones de CINT a sólo dos tipos: dependencias plurales y funcionales, 
y de momento vamos a considerar sólo estas últimas. 


DEPENDENCIAS FUNCIONALES 


Hemos mencionado ya este tipo de condiciones. 


Las dependencias funcionales son condiciones de integridad que se definen 
como sigue: 


Sean A y B subconjuntos propios de U (U es el conjunto de los atributos de una 
relación R). Decimos que A define funcionalmente a B en R si para dos tuplas 
cualesquiera de R que tengan iguales valores en A, también son iguales los valores 
de B. Se representa (A>B). 


NAMA pr PA bo £ 
poe A ) 


Las dependencias funcionales son condiciones de integridad entre atributos 
de una misma relación. No permiten expresar condiciones entre atributos de 
relaciones diferentes. 


Por ahora vamos a considerar esquemas de diseño en los que todas las 
condiciones de integridad sean expresables como dependencias funcionales. En- 
tonces designaremos con DF al conjunto de condiciones aplicables, con lo que 
un esquema de diseño se representará (B, DF). 


Ejemplo: 
B: 

PED (ART, PROV, CANT, PRECIO, CIUDAD, KM) 
DF: 


(ART, PROV) >(CANT, PRECIO, CIUDAD, KM) 
ART>PRECIO 

PROV>CIUDAD 

CIUDAD>KM 


PED | ART | PROV | CANT | PRECIO [CIUDAD 


La primera DF del ejemplo anterior indica que no puede haber dos tuplas 
con iguales valores en (ART, PROV), pues entonces las dos tuplas serían iguales, 
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lo que es imposible. Es decir, que (ART, PROV) es una superclave de la relación 
PED. 


Es evidente además que de unas DFs pueden inferirse otras. En el ejemplo 
anterior de 


PROV>CIUDAD 
CIUDAD>KM 


puede inferirse que, como a cada proveedor corresponde una ciudad, y a cada 
ciudad una distancia, también se puede decir que a cada proveedor corresponde 
una distancia, o sea: PROV>KM. 


Además, como (ART, PROV) toma valores únicos, podemos decir que: 


(ART, PROV)>CANT; 
(ART, PROV) >PRECIO; 
(ART, PROV)>CIUDAD; 
(ART, PROV)>KM; 


En definitiva, el conjunto DF dado es equivalente a: 


(ART, PROV)>(CANT, PRECIO, CIUDAD, KM); 
(ART, PROV)>CANT; 

(ART, PROV)>PRECIO; 

(ART, PROV)>CIUDAD; 

(ART, PROV)>KM; 

ART>PRECIO; 

PROV>CIUDAD; 

CIUDAD>KM; 

PROV>KM; 


Vemos por tanto que a partir de un conjunto de dependencias funcionales 
pueden inferirse otras. A continuación vamos a describir un sistema completo 
de reglas de inferencia aplicable a las dependencias funcionales. 


SISTEMA DE INFERENCIA PARA 
DEPENDENCIAS FUNCIONALES 


Diremos que una condición de integridad cualquiera se deduce o infiere de 
otras si se cumple en todas las extensiones posibles en que se cumplan éstas. 


Sea R un esquema de relación, U el conjunto de sus atributos y X, Y, Z, W, 
subconjuntos propios de U. Entonces puede demostrarse que se verifican las 
propiedades o reglas de inferencia siguientes: 
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1) Reflexividad: /7 2 => 1 2 YX 


SEX! entonces se verifica que (X> Y). 


2) Aumentación: 
Si (X>Y), entonces se verifica que (XZ>YZ). Hg: XU2 > xy 


(Nota: XZ es una notación para indicar el conjunto formado por todos los 
atributos incluidos en X o en Z, es decir, es lo mismo que (Xu Z)). 


3) Transitividad: 
Si (X>Y) y (Y>Z), entonces se verifica que (X=>Z). 


Estas propiedades forman un sistema completo de reglas de inferencia. Es 
decir, todas las dependencias funcionales inferibles de un conjunto dado se 
pueden obtener aplicándolas a éste. Además, es sano. Es decir, todas las 
dependencias funcionales que se obtienen aplicando estas reglas son inferibles de 
las dadas. Este conjunto de reglas suele conocerse como axiomas de Armstrong. 
A partir de ellas pueden deducirse otras propiedades interesantes, como las 
siguientes: 


e Unión: 
Si (X>Y) y (X>Z), entonces (X>YZ). 
En efecto, por aumentación: (X>XY), (XY—=ZY). 
De aqui, por transitividad: (X>YZ), c.q.d. 
e Pseudotransitividad: , 
Si (X>Y) y (WY->Z), entonces (WX-=Z). y Y 


ES 


En efecto, por aumentación: (WX=>WY). De aquí, por transitividad: 
(WX>Z), c.q.d. 


e Descomposición: e 
Si (X>Y) y (Z< Y), entonces (X>Z). 
En efecto, por reflexividad: (Y >Z). De aquí, por transitividad: (X>Z), 


c.q.d. 
e De las propiedades de unión y descomposición anteriores se deduce la 
siguiente: 
Si A,, A,, As, ..., A,, son los atributos de R, se cumple que (X>A, A, A; 
... A,) si, y sólo sí, se verifica que (X>A;), para todo i(¡=1, 2, 3, ..., n). 
CLAUSURA 


Dado un conjunto de dependencias funcionales, DF, llamaremos clausura de 
DF, y la representaremos por DF+, al conjunto de todas las dependencias 
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funcionales posibles que sean inferibles a partir de DF. Es decir, si aplicamos 
reiteradamente los axiomas de Armstrong a DF para inferir todas las dependen- 
cias funcionales que se pueda, todas ellas junto con DF, forman el conjunto, 
DF +, de la clausura de DF. 


El conjunto DF+ puede contener un gran número de elementos, por lo que 
puede ser prohibitivo ejecutar un algoritmo para construirlo. En cambio, sí 
existen algoritmos viables para determinar si una dependencia cualquiera dada, 
tal que (X>Y), está o no en DF+. Estos algoritmos nos permiten determinar 
si dos conjuntos dados de dependencias funcionales son equivalentes. 


Dos conjuntos de dependencias funcionales, DF1 y DF, son equivalentes si, 
y sólo si, (DF1 + =DF2+). Es decir, son equivalentes si todas las dependencias 
funcionales inferibles de DF1 también lo son a partir de DF2. O lo que es igual, 
si todas las dependencias de DF1 están DF2+, y todas las de DF2 están en 
DF1 +. O lo que es igual, si todas las dependencias de DF1 son inferibles a partir 
de DF?2, y viceversa. 


Ejemplo: 

DFl: 
(ART, PROV)>(CANT, PRECIO, CIUDAD, KM); 
ART>PRECIO; 
PROV>CIUDAD; 
CIUDAD>KM; 

DF2: 
(ART, PROV)>CANT; 
ART>PRECIO; 
PROV>CIUDAD; 
CIUDAD>KM; 


DF1 y DF?2 son equivalentes. 


RECONSIDERACIONES SOBRE LAS CLAVES 


Ya hemos dicho que si X toma valores únicos, no repetidos, en R, X es una 
superclave de R. Vamos a reconsiderar este concepto. 


Definición de superclave: 


Sean A,, Az, Az, ..., Aj, los atributos de R; X es una superclave de R si, y sólo 
si se verifica: 


EAS ¿HA 
Como ya se ha dicho anteriormente, si X es una superclave tal que ningún 


subconjunto propio de X sea también superclave, entonces se dice que X es una 
clave. 
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Definición de clave: 

X es una clave si, y sólo si, se verifican las dos condiciones siguientes: 
e X>(A,A,A;5...A,) 

e Ningún subconjunto propio de X, tal que Y, Y <X, verifica que 

(Y (A/A, ... Ap) 


En toda relación existe por lo menos una clave. En efecto, por reflexividad: 
(A, AA. ASADAS A) 
Luego, o bien (A,A, ... A,) es una clave, o bien lo es uno de sus subconjuntos. 


Añadiendo atributos a una clave se obtienen superclaves. 


De la definición anterior se deduce que si X es una superclave de R, toma 
valores únicos en R. En efecto, como (X>A,A, ... A,), si hubiera dos tuplas 
con valores repetidos de X, serían idénticas, lo que es imposible. 


Si X e Y son superclaves, se verifica que (X>Y) y (Y>X). 


Obsérvese que cuando decimos que se verifica (X>A,A, ... A,), queremos 
decir que esta dependencia funcional está en DF+ (aunque puede que no esté 
en DF). 


Ejemplo 1 
Supongamos que en la relación de Pedidos anterior sólo puede haber un provee- 
dor por ciudad, por lo que DEF es: 

(ART, PROV)>CANT; 

ART>PRECIO; 

PROV>.CIUDAD; 

CIUDAD>KM; 

CIUDAD>PROV; 


Aplicando los axiomas de Armstrong deducimos: 
(ART, PROV)>ART, (reflexibilidad) 
(ART, PROV)>PRECIO; (transitividad) 
(ART, PROV)>PROV,; (reflexividad) 
(ART, PROV) >CIUDAD); (transitividad) 
(ART, PROV)>KM; (transitividad) 
Por tanto, (ART, PROV) es una superclave. Como además es mínima, es decir, 


no se puede suprimir ninguno de sus componentes sin que deje de ser superclave, 
también es una clave. 


Por otra parte, por aumentación de la última DF de DF, tenemos que (ART, 
CIUDAD) >(ART, PROV), por lo que también (ART, CIUDAD) es una super- 
clave (y una clave, por ser minima). 

Ejemplo 2. 


Supongamos que dividimos cada ciudad del país en distritos que se numeran 
secuencialmente, de tal modo que un distrito puede contener una ciudad completa, 
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o una parte de ella, y que dentro de una ciudad no haya calles o plazas 
con el mismo nombre. Consideremos el esquema de relación siguiente: 


ZONAS (CIUDAD, DIRECCION, DISTRITO) 
Las dependencias funcionales, DF, serían: 
(CIUDAD, DIRECCION)>DISTRITO; 
DISTRITO >CIUDAD; 
De aquí, aplicando los axiomas de Armstrong, se deduce que hay dos claves: 
(CIUDAD, DIRECCION) y (DISTRITO, DIRECCION). 


PROPAGACION DE LAS DEPENDENCIAS lis ii 
AL DESCOMPONER 


Supongamos ahora que tenemos un esquema de relación R(A,, A,, ..., A,) 
y que A, B, C, son conjuntos de atributos que forman una partición de U (es 
decir, son subconjuntos propios de U, disjuntos, y cubren totalmente a U). Sea 
DF el conjunto de condiciones de integridad aplicables a R, formado por 
condiciones expresables todas como dependencias funcionales, y supongamos 
que (A>B) está en DF +. 


Como (A>B) implica que también se cumple que (AB), sabemos que si 
descomponemos R en S y T mediante proyecciones, esta descomposición es 
reversible por yunción. Es decir, cualquier extensión de R da lugar, proyectándo- 
la, a dos extensiones de S y T que al ayuntarlas reproducen la de R. 


Entonces el esquema de diseño: 


B=(R), 
DF tal que DF+ contiene a (AB), 


lo hemos transformado en: 
B"=(S, T), 

donde S=P(A, B) (R), T=P(A, C) (R), y 
CINT,, 


donde CINT' es el conjunto de condiciones de integridad aplicables a B', que 
será consecuencia de las condiciones, DF, aplicables a B. 


Vamos a ver cómo determinar este conjunto CINT'. Para ello veremos cómo 
se transforman las dependencias de DF al pasar de B a B. 


Supongamos que (X>Y) está en DF + y que (XY <AB). Entonces, las tuplas 
de S cumplen la condición (X=Y) también. En efecto, sean s, y sz dos tuplas 
de S con iguales valores en X. Estas tuplas se obtienen al proyectar R a partir 
de unas tuplas t, y t, de R, respectivamente. Como en R se verifica (X= Y), los 
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valores de Y en t, y t, serán iguales. Evidentemente, también lo serán en SY 
s2. Luego también en S se cumple (X>Y). 


Por tanto, si extraemos de DF+ todas las dependencias funcionales cuyos 
atributos están incluidos en AB, tenemos un conjunto, DFS, que es aplicable a 
S. Análogamente, extrayendo de DF + las dependencias funcionales cuyos atribu- 
tos están en AC, tendremos un conjunto, DFT, que es aplicable a T. 


Tendremos por tanto: 

e Primer esquema de diseño; 
(R, DF) 

e Segundo esquema de diseño: 
(S, DES), (T, DFT) 


DFS y DFT se han formado extrayendo dependencias funcionales de DF +. 
pero es posible que haya en DF+ dependencias funcionales que no figuren en 
DFS o DFT. Estas dependencias funcionales representan condiciones de integri- 
dad de B que no son expresables como dependencias funcionales en B'. Por 
tanto, las hemos perdido en el nuevo diseño, y en consecuencia, si no las tenemos 
en cuenta, cada vez que actualicemos el nuevo esquema B' podemos obtener 
extensiones inválidas. 


De modo más preciso: diremos que la descomposición de R en S y T preserva las 
dependencias funcionales si (DF +)=(DFS+)u(DFT +). 


No siempre se cumple esta condición.Vemos, pues, que es necesario que una 
descomposición por proyección cumpla las dos condiciones siguientes: 


1) Reversibilidad por yunción (que nos asegura que cualquier extensión válida 
de R puede reconstruirse a partir de sus proyecciones). 


2) Preservación de dependencias funcionales (que nos asegura que cualesquiera 
extensiones válidas de S y T, al ayuntarlas, nos producirán extensiones 
válidas de R). 

Ejemplo: 
Tomemos la relación ZONAS: 
ZONAS (CIUDAD, DIREC, DIST), con DF: 


(CIUDAD, DIREC)>DIST, 
DIST>CIUDAD; 


Proyectando sobre (DIST, CIUDAD) y (DIST, DIREC) obtenemos un segundo 
esquema de diseño: 


DISTRITOS (DIREC, DIST); 
AREAS (CIUDAD, DIST), 
DIST>CIUDAD; 


Hemos perdido la condición (CIUDAD, DIREC)>DIST. 
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Una extensión válida en el segundo esquema de diseño podría ser la siguiente: 


DISTRITOS | DIREC DIST AREAS | CIUDAD DIST 


Al ayuntar ambas obtenemos: 


DISTRITOS* AREAS | CIUDAD DIREC  — DIST 


BARNA c.A,l 10 
BARNA c.A,l 11 


Esta relación no es válida en el primer esquema de diseño, pues no cumple la 
DF: (CIUDAD, DIREC)>DIST. En consecuencia, si decidimos aceptar el diseño 
representado por el segundo esquema, cada vez que haya una actualización 
(añadido, modificación o borrado de tuplas), habrá que comprobar que a cada 
valor de (CIUDAD, DIREC) sólo corresponde un número de distrito. Esto 
implica hacer la yunción de DISTRITOS y AREAS para verificar sobre ella si se 
cumple (CIUDAD, DIREC)>DIST. Por tanto sería preferible adoptar el primer 
esquema de diseño. 


ANOMALIAS DE ACTUALIZACION 


Supongamos que en R se verifica que (X>Y) y que X no es una superclave. 
Entonces puede haber tuplas de R con iguales valores en X. Es decir, los valores 
de X pueden repetirse. Esto nos plantea algunas dificultades o anomalías en las 
Operaciones de mantenimiento. 


1) 


2 


A 


3) 


Anomalías de actualización o modificación. Cada vez que se actualice una 
tupla modificando el valor de Y, hay que comprobar si hay tuplas con 
igual valor de X que la que estamos actualizando, y en caso afirmativo, 
modificar también en ellas el valor de Y, para que se siga cumpliendo 
X> Y. Esta verificación podría ser responsabilidad del sistema, y si no, 
tendrá que hacerlo el programa de aplicación. 


Anomalías de borrado. Cada vez que se borre una tupla cuyo valor de X 
no esté repetido en ninguna otra, estamos perdiendo una información que 
hasta ese momento teníamos a nuestra disposición implícitamente, es 
decir, cuál es el valor de Y que corresponde a este valor de X. Esta 
información no se pierde si el valor de X está repetido en otras tuplas. 
Por tanto, la cantidad de información que se pierde al borrar una tupla 
no es siempre igual. 


Anomalías de inserción. Cada vez que se inserta una nueva tupla, hay que 
comprobar que su valor de Y es igual al que haya en las tuplas que tengan 
igual valor en X que la que estamos insertando. 
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El hecho de que en un esquema de diseño se presenten estas anomalías no 
lo invalida, en principio. Lo único que ocurre es que hay que hacer comproba- 
ciones adicionales, que pueden ser costosas en tiempo y accesos, al hacer 
actualizaciones. Además, si no se hacen correctamente, se pone en riesgo la 
integridad de los datos. 


Si suponemos que X>Y y que X es una superclave, no se presentan estas 
anomalías. Como X no puede tomar valores repetidos, no hay que comprobar 
si hay otras tuplas con el mismo valor de X que la que estamos insertando o 
actualizando en cada momento (no hay por tanto anomalías de actualización o 
inserción). En cuanto a los borrados de tuplas, todos suponen la misma pérdida 
de información, pues al no estar repetidos los valores de X, siempre se pierde la 
asociación del valor de Y correspondiente al X de la tupla borrada (no hay 
anomalías de borrado). 


En resumen, nos interesará, en principio, descomponer una relación proyec- 
tando sobre XY si se cumple que: 

e X>Y, y por tanto la descomposición es reversible por yunción. 

e X no es una superclave. 

e La descomposición preserva las dependencias. 


FORMA NORMAL DE BOYCE-CODD 


Vamos a designar con el nombre de dependencias funcionales triviales a 
aquellas que se pueden deducir sin más que aplicar los axiomas de Armstrong 
al conjunto, U, de atributos. O, dicho de otra forma, son aquellas que se 
cumplen en todas las extensiones posibles de R (sin ninguna restricción). Así, 
por ejemplo, serán dependencias triviales: 


(ABO)>A; (ABC)>(BO); etc. 
Definición de forma normal de Boyce-Codd: Una relación R está en forma normal 
de Boyce-Codd si para cualquier dependencia funcional no trivial, tal que X>Y, que 


esté en DF+-, se verifica que X es una superclave. La representaremos abreviada- 
mente por FNBC. 


De acuerdo con esta definición, las relaciones que están en FNBC no 
presentan las anomalías de actualización descritas en el apartado anterior. 


Toda relación R que no esté en FNBC, puede transformarse mediante 
proyecciones en otras que sí lo estén, mediante el algoritmo siguiente: 


Algoritmo de descomposición 


1) Tomemos una DF, tal como X>Y, que pertenezca a DF + y en la que 
X no sea una superclave y X e Y sean disjuntos. Esto siempre es posible, 
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a 


Y 


3) 


pues como R no está en FNBC, existe al menos una DF, tal que X>Z, 
donde el antecedente, X, no es una superclave. Es posible que X y Z sean 
disjuntos o no. Si no lo son, aplicando los axiomas de Armstrong podemos 
inferir que (X>(Z—X)), y aquí antecedente y consecuente son disjuntos. 
Por tanto, si R no es FNBC, siempre hay al menos una DF, X>Y, donde 
X no es superclave y X e Y son disjuntos. 


Obtengamos las proyecciones de R sobre (XY) y sobre (U— Y) (donde U 
es el conjunto de los atributos de R). Sean S y T estas proyecciones, 
respectivamente. Extraemos de DF+ las dependencias, DFS y DFT, 
aplicables a S y T respectivamente. 


Como (X>Y) está en DF+ y sus atributos son los de S, también es 
aplicable a S. Por otra parte, por aumentación: (X>XY), luego X es una 
superclave de S. Es decir, (X>Y) no viola en S la condición para FNBC. 


SiS o T no están aún en FNBC, podemos descomponerlas a su vez. Si 
algunas de las relaciones resultantes tampoco están en FNBC, las descom- 
ponemos a su vez, etc. 


Como en cada descomposición hemos hecho superclave al antecedente 
de una DF, llegará a un momento en que, o bien ya no habrá dependen- 
cias cuyos antecedentes no sean superclaves (es decir, todas las relaciones 
son FNBC), o bien habremos llegado a alguna relación binaria indescom- 
ponible que no esté en FNBC. Pero esto es imposible, pues si una relación 
binaria V(A,, A,) no es FNBC, quiere decir que hay una DF no trivial, 
A,>A,, donde el antecedente no es superclave, lo que es imposible porque 
de (A¡>A,)) se infiere (A, >A,A,)) y, por tanto, A, es superclave. 


En conclusión, cualquier relación que no esté en FNBC puede descomponerse 
en otras que sí lo estén. Además, por el procedimiento seguido, la descomposi- 
ción es reversible por yunción. Lo que no puede asegurarse en general es que se 
hayan preservado en este proceso las dependencias funcionales. 


Ejemplo 1: 
Tomemos la relacion ZONAS ya mencionada anteriormente. 
B: 
ZONAS (CIUDAD, DIREC, DIST); 


DF: 


(CIUDAD, DIREC)>DIST, 
DIST>CIUDAD; 


Claves: 


(CIUDAD, DIREC), 
(DIST, DIREC); 
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Como en (DIST>CIUDAD) el antecedente no es una superclave, la relación 
ZONAS no está en FNBC. 


Para normalizarla, la proyectamos sobre (DIST, CIUDAD) y sobre (DIST, 
DIREC), obteniendo las relaciones DISTRITOS y AREAS: 


DISTRITOS (DIREC, DIST) 
Clave: (DIREC, DIST) 
AREAS (CIUDAD, DIST) 
DIST>CIUDAD, 
Clave: (DIST) 


Tanto DISTRITOS como AREAS están en FNBC, pero, como ya vimos ante- 
riormente, esta descomposición no preserva las dependencias. En este ejemplo 
sería preferible aceptar el diseño no normalizado, aunque presente anomalías de 
actualización. 


Ejemplo 2: 
B: 
PEDIDOS (ART, PROV, NOMPRO, CANT) 
ART: Código de Artículo 
PROV: Código de Proveedor 


NOMPRO: Nombre de Proveedor 
CANT: Cantidad pedida 


DF: 
PROV>NOMPRO 
ART, PROV>CANT 
NOMPRO>PROV 


Claves: 


(ART, PROV) 
(ART, NOMPRO) 


Esta relación no está en FNBC, puesto que los antecedentes de las DFS 
(PROV>NOMPRO) y (NOMPRO>PROV) no son superclaves. Para normali- 
zarla vamos a proyectar sobre (PRO, NOMPRO) y (ART, PROV, CANT); 


PROVS: 


PROVS (PROV, NOMPRO); 
DF: 
PROV>NOMPRO, 
NOMPRO>PROV; 


Claves: 


(PROV), 
(NOMPRO); 
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PEDS: 
PEDS (ART, PROV, CANT); 
DF: 
(ART, PROV)>CANT; 


Claves: 
(ART, PROV); 


Estas dos relaciones están en FNBC. Además, la descomposición realizada 
preserva las DFS. En este caso, en principio, sería aconsejable adoptar el diseño 
normalizado (a menos que predominen los programas de consultas de la relación 
PEDIDOS sobre las actualizaciones). Una importante ventaja del diseño normali- 
zado obtenido es que puede contener más información que el primero. Por 
ejemplo, puede existir en PROVS una fila de un Proveedor sin que haya pedidos 
para él, lo que es imposible en el diseño de partida, en el que sólo se tiene 
información de los Proveedores que tienen Pedidos. 


Ejemplo 3: 
Sea el esquema: 
B: 
PR (P, CIUDAD, DISTN) 
Pp: Código de Proveedor 
CIUDAD: Nombre de la ciudad donde reside el Proveedor 
DISTN: — Distancia a que se encuentra la ciudad 
DF: 


P>CIUDAD 
CIUDAD>DISTN 


Claves: 
(P) 
Esta relación no está en FNBC, porque el antecedente de CIUDAD>DISTN no 
es una superclave. Obtenemos un segundo esquema de diseño proyectando: 
PC (P, CIUDAD); 


DF: 
P>.CIUDAD; 


Claves: 
(P); 
CD (CIUDAD, DISTN); 
DF: 
CIUDAD>DISTN; 


Claves: 
(CIUDAD); 


Ambas relaciones son FNBC, y se han preservado las DFS. 
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al 


Vamos a añadir a la relación anterior el atributo «coste de transporte», que será 


dependiente de la distancia: 


B: 
PR (P, C, D, T) 
P: Código de Proveedor. 
C: Nombre de la ciudad donde reside el Proveedor 
D: Distancia a que se encuentra la ciudad 
T: Coste de transporte 
DF: 
P>C 
C>D 
D>T 
Claves: 
(P) 


No está en FNBC. Vamos a descomponer proyectando sobre (CD): 


PRI (C, D); 
DF: 
C>D; 


Claves: 
(C);, (Está en FNBO); 


PROMPC:T) 
DF: 
P>C, 
C>T; 
Claves: 
(P);, (No es FNBO); 


Como PR2 no es FNBC, vamos a descomponerla a su vez en dos: 
PR3'(C, T); 
DF: (C>T); 
Claves: (C); 
Es FNBC; 
PR4 (P, C); 
DF: P>C; 
Claves: (P); 
Es FNBC; 
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Hemos llegado, pues, a un esquema de diseño con tres esquemas de relación, PR1, 
PR3 y PR4, donde todas las relaciones están en FNBC. Pero en el proceso de 
descomposición no se han preservado las DFS, pues hemos perdido la DF(D>-T). 
Por ejemplo, una extensión válida en el segundo esquema de diseño podría ser: 


Al ayuntar estas relaciones obtendriamos: 
PECAED. 1 


PIuCl- D1 TL 
PZ4CZ DI 12 


Esta relación no es válida en el primer esquema de diseño porque no cumple la 
condición (D>T). 


El proceso de normalización de una relación dada según el algoritmo de 
descomposición puede no ser único. Veámoslo en un ejemplo: 


Ejemplo 5: 


Tomemos de nuevo el esquema; del ejemplo anterior. La primera descomposición 
puede hacerse proyectando sobre (DT) en vez de (CD) como antes. Obtendriamos: 


PRI(D:T): 
DF: D>T; 
Claves: (D); 
Es FNBC; 

PR6 (P; C,-D); 
DF: P>.C, C>D; 
Claves: (P); 
No es FNBC; 


Descompongamos ahora PR6: 


PR7 (C, D); 
DF: C>D; 
Claves: (C); 
Es FNBC; 

PR8 (P, C); 
DF: P>C; 
Claves: (P); 
Es FNBC; 


Hemos obtenido un tercer esquema de diseño, con las relaciones PR5, PR7 y PR8, 
todas ellas normalizadas, y hemos preservado las DFS. Además es un esquema 
intuitivamente más lógico. 
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Muchos de los problemas relacionados con la teoría de normalización 
tienen la propiedad de ser «NP-completos», lo que significa que, con una gran 
probabilidad, son inherentemente exponenciales. Así se ha demostrado para el 
problema de dictaminar si una relación está o no en FNBC, y también para el 
problema de hallar una clave de tamaño mínimo para una relación dada. 


TERCERA FORMA NORMAL 


Hemos visto que una relación está en FNBC si tiene la propiedad de que 
para todas las DFs no triviales incluidas en DF +, sus antecedentes son supercla- 
ves. Podemos relajar algo esta condición y llegar así a otras formas normales. 
Veamos la tercera forma normal (FN3). 

Supongamos que admitimos que en algunas dependencias los antecedentes 
no sean superclaves, siempre que los consecuentes sean atributos incluidos en 
alguna clave. Entonces la relación está en tercera forma normal. 

Para precisar el enunciado anterior vamos a definir como atributos principa- 
les («prime attributes») a aquellos que participan en alguna clave. 

Definición 
Diremos que una relación está en tercera forma normal (FN3) si para toda DF no 


trivial de DF + se verifica alguna de las condiciones siguientes: 
e O bien el antecedente es una superclave. 


e O bien el antecedente no es una superclave y el consecuente es un conjunto 
de atributos principales. 


Es evidente, de acuerdo con esta definición, que toda relación que esté 
en FNBC también está en FN3. El recíproco no es siempre cierto. Veamos 
algunos ejemplos. 


Ejemplo 1: 
Tomemos la relación ZONAS: 

B : ZONAS (CIUDAD, DIREC, DIST) 

DF: (CIUDAD, DIREC)>DIST; DIST>CIUDAD. 
Claves: (CIUDAD, DIREC); (DIST, DIREC) 


El antecedente de (DIST>CIUDAD) no es una superclave, luego ZONAS no 
está en FNBC. Pero el consecuente es un atributo principal (forma parte de la 
clave (CIUDAD, DIREC)), luego sí está en FN3. 


Ejemplo 2: 
Tomemos la relación PEDIDOS, ya mencionada anteriormente: 
B: 
PEDIDOS (ART, PROV, NOMPRO, CANT) 
ART: Código de Artículo 
PROV: Código de Proveedor 


NOMPRO: Nombre de Proveedor 
CANT: Cantidad pedida 
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DF: 


PROV>NOMPRO 
ART, PROV>CANT 
NOMPRO>PROV 


Claves: (ART, PROV); (ART, NOMPRO) 


Esta relación no está en FNBC, puesto que los antecedentes de las DFs (PROV> 
NOMPRO) y (NOMPRO>PROV) no son superclaves, pero sí está en FN3 
porque los consecuentes son atributos principales. 


Ejemplo 3: 


Tomemos la relación PR, ya mencionada anteriormente: 
B: 
PRA(E:Cs DU) 
P: Código de Proveedor 
C: Nombre de la ciudad donde reside 
D: Distancia a que se encuentra ésta 
T: Coste de transporte 
DF: 
(P=.C); (CD); (D>T) 
Claves: (P) 


No está en FNBC ni en FN3. 


Toda relación que no esté en FN3 puede descomponerse en otras que sí lo 
estén mediante proyecciones reversibles por yunción, aplicando el mismo algo- 


ritmo de descomposición expuesto anteriormente para descomponer en FNBC. 
Recordémoslo: 


Algoritmo de descomposición 


1) Tomemos una DF, X>Y, donde X e Y sean disjuntos y X>Y viole las 
condiciones de FN3, es decir, X no sea superclave e Y contenga algún 
atributo no principal. 

Esto siempre es posible. 


2) Obtengamos (S=P(XY) (R)) y (T =P(U— Y) (R)). Como ya vimos, X > Y 
no viola ya las condiciones de FN3 en S, porque X es una superclave de $. 


3) Si S o T no son FN3, se vuelven a descomponer, etc. 


4) En cada una de estas descomposiciones se ha eliminado una DF que viola 
las condiciones de FN3. Como hay un número finito de DFs, llegará un 
momento en que no habrá ninguna DF que viole las condiciones o 


tendremos relaciones binarias. Pero éstas son FN3 (puesto que, como ya 
vimos, son FNBC). 
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Este algoritmo, como ya vimos al hablar de FNBC, produce descom- 
posiciones reversibles por yunción, pero puede no preservar las DFs. 


Ejemplo 4: 
Descomposición en FN3. Tomemos la relación de Pedidos siguiente: 
PE (A, P, NP, CAN, CIU) 
A: Código de Artículo 
p: Código de Proveedor 
NP: Nombre de Proveedor 
CAN: Cantidad pedida 
CIU: Ciudad del Proveedor 


DF: 
A, P>CAN 1 P- 
P >NP E 
NP >P 
y. cdi Pp  =>CIU Je el 


U Claves: (A, P); (A, NP) 


La DF (P>.CIU) viola las condiciones de FN3. Proyectemos sobre (P, CIU), por 
tanto, para obtener PEl y PE2: 


PEl (P, CIU); 
DF: (P>.CIU); 
Clave: (P) 
Es FN3 (y FNBC) 
PE2 (A, P, NP, CAN); _ dar 
DF: (A, P>CAN), (P>NP), (NP>P); 
Claves: (A, P), (A, NP); 
Es FN3 (pero no FNBC) 


Hemos llegado a un diseño (PE1, PE2), que es reversible por yunción y preserva 
las DFs. 


Como PE2 no es FNBC, convendría descomponerla a su vez, y obtendriamos el 
diseño: 


PE] (P; CIU) 


PROVS (P, NP), 
PE3 (A, P, CAN); 


donde todas las relaciones son FNBC y además se preservan las DFs. 


Sin embargo, este diseño, obtenido aplicando el algoritmo de descomposición 
directamente sobre las DFs dadas, es mejorable si lo aplicamos sobre DFs 
deducidas de las dadas. En efecto, de (P—>NP) y (P>-CIU) se infiere que (P>NP, 
CIU). Esta DF viola las condiciones de FN3 y de FNBC, pues el antecedente no 
es una superclave y el consecuente, (NP, CIU), tiene un atributo no principal. 
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Vamos, pues, a descomponer proyectando sobre esta DF, obteniendo PE4 y 
PES: 


PE4 (P, NP, CIU); 
DF: (P>NP), (NP>P), (P=>.CIU); 
Claves: (P), (NP); 
Es FNBC. 


PES (A, P, CAN); 
DF: (A, P>CAN); 
Clave: (A, P); 

Es FNBC. 


Este diseño es reversible por yunción, preserva las DFs y sólo tiene dos relaciones. 
Es por tanto preferible al anterior (formado por PE1, PROVS y PE3). Además, 
es intuitivamente más lógico. 


DEPENDENCIAS PARCIALES Y TRANSITIVAS 


Diremos que un atributo, A, depende transitivamente de una clave X 
cualquiera si Á es no principal y existe una dependencia (Y >A), donde Y no es 
una superclave ni parte de una clave. 


Diremos que un atributo A depende parcialmente de una clave X, si A es no 
principal y existe una dependencia (Y >A), donde Y es parte de la clave X. 


De acuerdo con estas definiciones, si una relación está en FN3, no tiene 
dependencias parciales ni transitivas, pues si hubiera alguna se violarían las 
condiciones que debe cumplir una relación FN3. 


Recíprocamente, si no hay dependencias parciales ni transitivas, la relación 
está en FN3. En efecto, si no lo estuviera, habría alguna DF, tal que Y>A, 
donde Y no fuera superclave y A fuera no principal, es decir, habría alguna 
dependencia parcial o transitiva. 


En resumen, una relación está en FN3 si, y sólo si, no tiene dependencias parciales 
ni transitivas. 


DESCOMPOSICION PRESERVANDO LAS DEPENDENCIAS 
FUNCIONALES 


Sea una relación, R, y sea DF el conjunto de sus dependencias funcionales. 
Supongamos que DF es un cubrimiento mínimo de DF +, es decir, que cumple 
las condiciones siguientes: 


1) Todas las dependencias tienen un solo atributo en su consecuente (es decir, 


detrás de la flecha). Si así no fuera se descompone. Por ejemplo, X>AB 
se descompondría en X>A y X>B. 
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2) No hay en DF dependencias redundantes. O lo que es lo mismo, ninguna 
DF de DF puede inferirse de las restantes, o lo que es igual, si se suprime 
de DF una DF cualquiera, ya no podrían inferirse de las que queden todas 
las DFs de DF+. 


3) No hay atributos redundantes en ningún antecedente de DF. Es decir, que 
no se puede suprimir ningún atributo en la parte izquierda de las depen- 
dencias de DF sin que esto afecte a DF+. 


Vamos a descomponer R mediante el siguiente procedimiento. 


Algoritmo de descomposición que perserva dependencias 


e Entrada: R. 
e Salida: n relaciones obtenidas a partir de R. 
e Proceso: 
1) Si hay atributos en R que no figuran en los antecedentes o consecuentes 
de DF, proyectar R sobre ellos. Poner la relación resultante en la salida. 


2) Si en alguna DF de DF figuran todos los atributos de R (bien en el 
antecedente, bien en el consecuente), poner R en la salida. 


3) Si hay en DF varias DFs con el mismo antecedente, tal como X>A, 
X>B, ..., etc., proyectar R sobre (X, A, B, ...). Poner la relación 
resultante en la salida. 


4) Tomar una DF de DF cuyo antecedente no esté repetido en ninguna 
otra, tal como Y >D, y proyectar R sobre (Y, D). Poner la relación 
resultante en la salida. 

5) Repetir los pasos 3 y 4 anteriores hasta que se hayan tratado todas las 
DFs de DF. Cuando se haya terminado con la última, pasar al punto 
siguiente. 

6) Proyectar R sobre una cualquiera de sus claves. Poner la relación 


resultante en la salida. Fin del algoritmo. 


Es evidente que este algoritmo preserva las DFs. Puede demostrarse además 
que es reversible por yunción y que todas las relaciones obtenidas son FN3. Por 
tanto, puede ser preferible al algoritmo de descomposición descrito anteriormen- 
te. El problema con este algoritmo es que suele producir relaciones redundantes. 


Ejemplo 1: 

Sea el esquema: 
R(A, B, C); 
DF: B>C; 
Clave: (A, B). 
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Aplicando el algoritmo tendríamos: 
R1(A) (puesto que A no participa en las DFs dadas) 
R2(B, C) 
R3(A, B) (por ser (AB) una clave) 
Evidentemente, R1(A) es redundante con R3(A, B), puesto que ésta contiene los 
atributos de aquélla. Tendremos, en definitiva, el diseño siguiente: 
RA(BICT 
(B>-0), 
FNBC. 
R3(A, B), 
Clave: (A, B), 
FNBC. 


Ejemplo 2: 
Sea el esquema: 
R(AB..€; D,:E, F, 6); 


DF: B, C>D, 
E >F, 
E >G; 


Clave: (A, B, C, E). 


Aplicando el algoritmo se puede descomponer en: 

R4 (A), 

FNBC. 

R5:(B+€, DD), 
BC>D, 

Clave: (BC), 
FNBC. 

R6 (E, F, G), 
(E>F), (E>6), 
Clave: E, 
FNBC. 

R7(A, B, C, B), 
FNBC. 


Evidentemente, R4 es redundante con R7. 


Ejemplo 3: 
CURSO (AS, P, AU, H, AL, C) 

AS: Asignatura 

P: Profesor 

AU: Aula 

H: Hora 

AL: Alumno 

C: Calificación 
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Conjunto de dependencias, DF: 


e Cada asignatura tiene un solo profesor, (AS=P). 


e En un momento dado, un aula está ocupada por una sola asignatura, 
(H, AU>AS). 


e En un momento dado, un profesor sólo puede estar explicando en un aula, 
(H, P>AU). 


e Cada estudiante tiene una sola calificación por asignatura, (AS, AL=-C). 


e En un momento dado, un estudiante sólo puede estar en un aula, 
(H, AL>AU). 


Sólo hay una clave: (H, AL). Además DF es un cubrimiento mínimo de DF +. 


Vamos a normalizar la relación CURSO, según el algoritmo de descompo- 
sición que nos permite la obtención de relaciones en FNBC. El proceso es el 
siguiente (se señala en cada paso con un x* la DF elegida para proyectar): 


Relación de partida: 
CURSO (AS, P, AU, H, AL, C) 
AS >P 
H AU>AS 
H P>3AU 
* AS AL>C Y 

H AL>AU 
Clave: (H, AL) 


Proyectando sucesivamente se obtiene: 


CURI (AS, AL, C) 
AS AL>C 
Clave: (AS, AL) 
FNBC 
CUR2 (AS, P, AU, H, AL) 
* AS >P 
H AU>AS 
TB [Ape 
H AL>AU 
Clave: (H, AL) 
CUR3 (AS, P) 
AS >P 
Clave: (AS) 
FNBC 
CUR4 (AS, AU, H, AL) 
H AU>AS 
* H AS>AU 
H AL>AU 
Clave: (H, AL) 
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CURS (AS, AU, H) 
AS H >AU 
AUH >AS 
Claves: (AS, H) y (AU, H) 
FNBC 


CUR6 (AS, H, AL) 
H AL>AS 
Clave: (H, AL) 
FNBC. 


En resumen, hemos llegado así al diseño: 


CURI (AS, AL, C): Calificaciones por alumno y asignatura. 
CUR3 (AS, P): Profesores de las asignaturas. 

CURS (AS, AU, H): Horarios y aulas por asignatura. 
CUR6 (AS, H, AL): Alumnos por cada asignatura y hora. 


En el proceso de descomposición hemos perdido la DF (H, P>AU), al pasar 
de CUR2 a CUR4. 


Apliquemos ahora a CURSO el algoritmo de descomposición que preserva depen- 
dencias. Obtenemos el siguiente esquema: 


CUR7 (AS, P) 
AS >P 
Clave: (AS) 
FNBC 

CURS (AS, AU, H) 
AS H >AU 
AUH >AS 
Claves: (AS, H) y (AU, H) 
FNBC 

CUR9 (P, AU, H) 
H P >AU 
H AU>P 
Claves: (H, P) y (H, AU) 
FNBC 

CURIO0 (AS, AL, C) 
AS AL>C 
Clave: (AS, AL) 
FNBC 

CUR11 (AU, H, AL) 
H AL>AU 
Clave: (H, AL) 
FNBC 
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CUR12 (H, AL) 
Clave: (H, AL) 
FNBC. 


Evidentemente, CUR12 está contenida en CUR11. Además, CUR7 es igual que 
CUR3, CUR$ que CURS y CURI0 que CUR], por lo que queda finalmente 
el diseño: 

CUR1 (AS, AL, C): Calificaciones por alumno y asignatura. 

CUR3 (AS, P): Profesores de las asignaturas. 

CURS (AS, AU, H): Horarios y aulas por asignatura. 

CUR9 (P, AU, H): Horarios y aulas por profesor. 

CUR11 (AU, H, AL): Alumnos por aula y hora. 


Este diseño contiene más redundancia que el anterior, pero preserva las dependen- 
cias y aquél no. 


SEGUNDA FORMA NORMAL 


Se define relajando algo las condiciones de FN3. Vamos a describirla a 
continuación por su interés histórico. 


Una relación está en segunda forma normal (FN2) si para toda DF de DF+ no 
trivial se verifica una de las condiciones siguientes: 
e O bien el antecedente es una superclave. 
e O bien el antecedente no es una superclave y el consecuente es un conjunto 
de atributos principales. 


e O bien, si el antecedente no es una superclave ni el consecuente un conjunto 
de atributos principales, el antecedente no es parte de ninguna clave. 


Es evidente, por la definición anterior, que toda relación que esté en FN3 
también está en FN2. El recíproco no es cierto. 


Si una relación no tiene dependencias parciales, está en FN2, pues si así 
no fuera, habría una dependencia, Y >A, donde Y no sería una superclave, 
A sería no principal e Y sería parte de alguna clave (para violar las tres 
condiciones que definen una FN2). Es decir, habría una dependencia Y>A, 
que sería una dependencia parcial, lo que contradice la hipótesis. 


Recíprocamente, si una relación está en FN2, no tiene dependencias parciales, 
pues si hubiera alguna contradiría las condiciones anteriores. 


En resumen, para que una relación esté en FN2 es condición necesaria y suficiente 
que no tenga dependencias parciales (aunque sí puede tener dependencias transitivas). 


Sólo para completar el panorama mencionaremos la existencia de lo que 
se conoce como primera forma normal. Una relación está en esta forma 
normal cuando sus atributos son indescomponibles (es decir, no hay subcam- 
pos dentro de campos). Nosotros, al definir las relaciones, hemos considerado 
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dominios formados por conjuntos de valores indescomponibles, es decir, que 
no son a su vez conjuntos. Por ello, desde el principio hemos implícitamente 
supuesto que todas las relaciones a que nos referíamos eran en primera forma 
normal. 


Toda relación que no esté en FN2 puede descomponerse en otras que sí 
lo estén, mediante proyecciones. 


Una relación que esté en FN2 puede presentar anomalías de actualización 
suprimibles al descomponerla en relaciones FN3. También al descomponer 
una FN3 en otras FNBC se pueden eliminar anomalías. Por tanto, en principio, 
interesa descomponer en FNBC si se preservan las dependencias en la descompo- 
sición. Si no, se puede al menos descomponer en relaciones FN3, preservando 
las dependencias. 


Ejemplo 1: 
Tomemos la relación PR, ya comentada anteriormente: 
BPR (P, CD T) 
P: Código de Proveedor 
C: Nombre de la ciudad donde reside 


D: Distancia a que se encuentra ésta 
T: Coste de transporte 


DF: (P>-C); (C>.D); (D>T) 
Claves: (P) 


No está en FNBC ni en FN3, pero sí está en FN2 (los antecedentes de C>D 
y D>T no forman parte de ninguna clave). 


Ejemplo 2: 
Tomemos ahora la relación de Pedidos, PE, anteriormente comentada: 
PE (A, P, NP, CAN, CIU) 
A: Código de Artículo 
Pp; Código de Proveedor 
NP: Nombre de Proveedor 
CAN:Cantidad pedida 
CIU: Ciudad del Proveedor 
DF: (A, P)>CAN; P>NP; NP>P; P>CIU 
Claves: (A, P); (A, NP) 


No es FNBC ni FN3. Tampoco es FN2 porque en (P>CIU) el antecedente 
es parte de una clave. 


DEPENDENCIAS PLURALES 
Hemos visto que, dada una relaciom R y un conjunto de DFs definidas 


sobre ella, se puede descomponer en relaciones FNBC o FN3 con reversibili- 
dad por yunción. 
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Vamos ahora a plantearnos el mismo problema, pero con condiciones de 
integridad más generales que las DFs. Vamos a considerar el caso en que 
nuestro conjunto de condiciones de integridad esté formado por DFs y DPs 
(o sea, dependencias funcionales y plurales). Representaremos con DEP al 
conjunto dado de DFs y DPs que se verifican en la relación. 


Recordemos que A>»B significa que si hay en R dos tuplas con el mismo 
valor en A, también existen en R las que resulten de intercambiar entre ellas los 
valores de B. 


SISTEMA DE INFERENCIA PARA 
DEPENDENCIAS PLURALES 


Análogamente a los axiomas de Armstrong para DFs, existen unos axio- 
mas aplicables a las DPs y DFs que permiten inferir unas de otras. Estos 
axiomas forman también un sistema de inferencias sano y completo (es decir, 
todas las dependencias inferibles lógicamente a partir de DEP pueden dedu- 
cirse aplicándoles los axiomas, y recíprocamente). Sea una relación R, con un 
conjunto U de atributos, con un conjunto dado, DEP, de dependencias funciona- 
les y plurales, y sean X, Y, Z, V, W, subconjuntos de U. Los axiomas son los 
siguientes: CEL Ay A 

1) Reflexividad de DFs: Si (Y <X), entonces X>Y. t Ls ,% 

2) Aumentación de DFs: Si (X>Y), entonces (XZ>YZ). 

g 3) Transitividad de DPs: Si (X>Y) y (Y>-Z), entonces (X>.Z). 

4) Complementación de DPs: Si (X>Y), entonces X>((U—X-— Y). 

5) Aumentación de DPs: Si (X>Y) y (VE W), entonces (WX>VY). //41 

6) Transitividad de DPs: Si (X>Y) y (Y5»Z), entonces (X>»Z— Y). 

7) Paso de DF a DP: Si (X>Y), entonces (X>>Y). 

8) Paso de DP a DF: Si (X>Y) y Z es una parte de Y (es decir, Z<Y) y 

(W=Z), siendo Y y W disjuntos, entonces se cumple que (X>Z). 


XK —=>> Y Ut 2] 
De estos axiomas pueden deducirse otras propiedades interesantes, como 


las siguientes: fe 
X 


1) Reflexividad para DPs: Si (Y <X), sabemos que X>Y, luego también 
se cumple que X>Y. 
2) Si (X>>Y) y (X>>Z), entonces (X>>Y —Z). Puede comprobarse mediante 
los pasos siguientes: ¿Ñ 
XoY; X>Z; XZ>YZ; X>XZ; X>YZ—XZ; Y1Z-XZ=Y —X-Z: 
X>Y —X—Z; X U(XN(Y—Z)=X; (Y —X—Z) uU(Xn(Y—Z)=Y-—Z; 
aumentando ambos lados de la última DP con (X n (Y —Z)), queda 
X>Y —Z. 
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3) Regla de descomposición: Si (X>Y) y (X>»Z), entonces se cumple que 
(X> Y —Z), (X>Z-—Y) y (X>Y n Z). Se deduce fácilmente de la propie- 
dad anterior. El nombre de esta regla se ve mejor si se pone en la forma: 


Si (X>YZ) y (X>ZV), siendo Y, Z y V, disjuntos, entonces (X> Y), 
(X>Z) y (X>V). 


4) Si (X>>Y), entonces (X>Y — X). 
5) Complementación del consecuente: Si (X>>Y), entonces (X>»U — Y). 
6) Regla de unión: Si (X>Y) y (X>»Z), entonces (X>YZ). 


Llamaremos DP triviales a las que se cumplen en cualquier extensión de R 
que pueda construirse, sin ninguna restricción. Dicho de otra forma, son triviales 
todas las DFs y DPs que se puedan inferir aplicando los axiomas a U. Para 
toda DP, (X-»Y), trivial, se cumple que, o bien (Y <X), o bien (XY =U0). 


Por ejemplo, son triviales: 
U>sX; XY>X; XY>Y; X>X nN Y; etc. 


Es más interesante el caso en que (XY =U). Comprobemos que, en este caso, 
X>Y es trivial: 


X>X; X>U-—X; X>YX-X; XoY—X; X>X Nn Y; X (Y —X)u(Y n X), 
de donde, finalmente, X->Y. 


Análogamente a como hacemos con las DFs, podemos definir la clausura de 
DEP, y la representaremos DEP +, como el conjunto de todas las dependencias 
inferibles de DEP aplicando los axiomas. Dos conjuntos de dependencias, DEP 
y DEP” serán equivalentes si DEP+ =DEP"+. 


TRANSFORMACION DE LAS DEPENDENCIAS 
PLURALES AL DESCOMPONER 


Análogamente a como hacíamos con las DFs, vamos a ver cómo aplicar las 
dependencias plurales de una relación a las que resulten de descomponerla en 
otras mediante proyecciones. 


Sea una relación R, con un conjunto DEP de DFs y DPs. Supongamos que 
S es una relación obtenida proyectando R. Sea U el conjunto de los atributos 
de R y V el de los atributos de S. Entonces: 


e Para toda DF, X>Y, de DEP +, tal que (X<V), la DF(X>Y n V) se 
verifica en S. 


e Para toda DP, X>Y, de DEP +, tal que (X<V), la DP(X>Y n V) se 
verifica en S. 
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Veamos algunos ejemplos. 


Ejemplo 1: 


Tomemos la relación CURSO ya estudiada anteriormente. Además de las DFs ya 
comentadas, parece lógico, de acuerdo con el significado de los atributos, que a 
cada asignatura. correspondan varias horas y aulas, independientemente de los 
profesores y alumnos que asistan a la clase. Esta condición equivale a decir que 
la asignatura pluridefine a la hora y aula, o sea, (AS>H, AU). En definitiva, el 
esquema de relación de CURSO será ahora: 


CURSO (AS, P, AU, H, AL, C) 


(Atributos: ASignatura, Profesor, AUla, Hora, ALumno, Calificación.) 


DEP: AS 
AS >P A 
H-AU>AS n 
H P >AU vd 
AS AL>C A 21 
H AL>AU 
AS —>—HAU 


Clave: (H, AL) 


Obsérvese que de estas dependencias se infiere: 


AS>H AU; WA 

AS>P AL C:; (complementación)  A%>= yO AU -A 
/ AS>P; AS>P; A S ap 

AS>AL C; copo l 


es decir, a una asignatura corresponden varios valores de la pareja (AL, C), 
independientemente de los profesores y aulas. 


Con estas condiciones podríamos tener un cuadro de valores como el siguiente: 


Aula 1 Aula 2 
Hora  Asig. Prof.  Alum. Calif. Asig. Prof.  Alum. Calif. 
9-10 Latín PI A11 E Matem. P2 A13 
A12 A Al4 


10-11 Gramát. P4 All 
A12 


Química P3 A13" 
A14 


Matem. P2 A13 
A14 


11-12 Latín P1 All 
A12 


Física P3 A13 
A14 


12-13 Histor. Pl A11 
A12 


mmHA| >| m>|n> 


m> | >=-m|un> 
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La extensión de la relación CURSO correspondiente a estos valores sería: 


CURSO AS H AU... AL. E. E 


up 9-10 Aul All P1 
>“ Latín 9-10 Aul Al2 Pl 
Latín 11-12 Aul ATT Pr 

Latín 11-12 Aul MUA Pl 

AL >» Bed | Matem. 9-10  Au2 'A13 P2 


Matem. 9-10  Au2 'A14 
Matem. 11-12 Au2 MAIS 
Matem. 11-12 Au2 "AT 
Gramát. 10-11 Aul All 
Gramát. 10-11 Aul Al2 
Física 12-13 Au2 A13 
Fisica 12-13 Au2 Al4 
Química 10-11 Au2 A13 
Química 10-11  Au2 Al4 
Histor. 12-13 Aul All 
Histor. 12-13 Aul A12 


m0>m>mmu >>> >md>m 
"Y 
mn 


Se ve que efectivamente (AS>H AU), pues si tomamos dos filas con el mismo AS: 


Latín 9-10 Aul All E Pl, 
Latín 11-12 Aul A12 A Pl, 
e intercambiamos entre ellas los valores de H y AU, se obtienen otras dos filas de 
la relación: 
Latín 11-12 Aul All E Pl, 
Latin 9-10 Aul A12 A Pl. 
Para normalizar esta relación, vimos que se podía empezar proyectando sobre 
(AS, AL, C) y (AS, P, AU, H, AL). Veamos cómo se propagan las DFs y DPs 
a las relaciones resultantes de estas proyecciones: 
CURI (AS, AL, C) 
AS AL>C 
Clave: (AS, AL); 
CUR2 (AS, P, AU, H, AL) 


AS >P 

HAU >AS 

HP  >AU 

HAL >AU 

AS >H AU 
Ejemplo 2: 


Supongamos ahora que existe otra condición de integridad adicional sobre la 
relación CURSO que es la siguiente: un alumno no recibe más de una clase al 
día de una asignatura dada. Si suponemos que el horario de clases se repite 
diariamente, esta condición equivale a decir que (AL, AS) toma valores únicos, 
es decir, es una superclave. Por tanto: (AL AS>P AU H C). Como (H AL) es 
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clave, de (AL AS>H) se deducen las demás (AL AS>P; AL AS>AU;AL 
AS>:C). 


Tenemos entonces que DEP es: 
AS >P 
H AU >AS 
HP => AU 
AS AL>C 
H AL >AU 
AL AS>H 
AS >H AU 
Aplicando los axiomas de inferencia: 


De AS>H AU y AS AL>AU, y teniendo en cuenta que (H AU) y (AS AL) 
son disjuntos, se deduce que (AS>AU). 


Análogamente, de AS>H AU y AS AL>H se deduce AS>H. 
Por tanto, AS>H AU. 


Es decir, la DP dada es en realidad una DF. Su significado es que una asignatura 
sólo se explica una vez al día, en un aula y a una hora determinadas. 


Tendremos en resumen que DEP es equivalente a: 


AS >P 
HAU >AS 
HP => AU 
AS AL>C 
HAL >AU 
AS >H 
AS =>AU 


(Claves: (H AL), (AS AL)) 


ANOMALIAS DE ACTUALIZACION CON DPs 


Supongamos que en R se verifica (X>Y) y que X no es una superclave. 
Análogamente a como razonábamos en el caso de DFs, se presentan anomalías 
de actualización por poder tomar X valores repetidos (y, por tanto, poder haber 
información redundante). 


Ejemplo: 


Tomemos la relación CURSO mencionada en el Ejemplo 1 de las páginas 
precedentes, en la que (AS>H AU) y AS no es una superclave. 


Si queremos actualizar la calificación de Latín del alumno A11, hay que hacerlo 
en varias filas (en todas las que aparezca el alumno All con la asignatura de 
Latín). (Anomalías de actualización.) 


Si se decide dar en el centro una clase más de una asignatura, por ejemplo Historia 
en el aula 1 de 13h. a 14h., no se puede registrar esta información en la relación 
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CURSO hasta que haya un profesor y, al menos, un alumno matriculado para 
esta clase. (Anomalía de inserción.) 


Análogamente, al borrar unas filas puede perderse más información que al borrar 
otras. (Anomalía de borrado.) 


CUARTA FORMA NORMAL 


Sea una relación R, con un conjunto DEP de DFs y DPs. 


Decimos que R está en cuarta forma normal (FN4) si para toda DP no trivial, tal 
que X>>Y, de DEP-+, el antecedente X es una superclave de R. 


Como X>Y, implica que X=>»Y, toda relación que está en FN4 también está 
en FNBC. 1s 


e 


Toda relación R se puede descomponer en relaciones FN4 de forma reversible 
por yunción. El algoritmo es el mismo que se describió anteriormente para 
descomponer en FNBC. Lo resumimos a continuación: 


Algoritmo de descomposición 


1) Tomar una DP de DEP+ cuyo antecedente no sea superclave. Sea esta 
DP, por ejemplo X>Y, y sean X e Y disjuntos. 


Si X e Y no fueran disjuntos, tomaríamos la DP (X>Y—X) en vez de 
X>Y, y en la que antecedente y consecuente son disjuntos. 


2) Obtener S=P(X, Y) (R) y T=P(U—Y) (R). Hallar las DFs y DPs 
aplicables a S y T a partir de DEP+. La DP de partida, X>*Y, es 
aplicable a S, pero no viola ya la condición de FN4 porque es trivial. 


3) SiS o T no son FN4, aplicarles el mismo proceso. 


Ejemplo 1: 

Tomemos la relación CURSO: 
CURSO (AS, P, AU, H, AL, C) 
(Atributos: ASignatura, Profesor, AUla, Hora, ALumno, Calificación.) 

DEP: 
AS >P 

X H AU>AS 
H P > AU 
AS AL>C 
H AL>AU 
AS >H AU 


Clave: (H, AL) 
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Para normalizar proyectaremos según los pasos siguientes: 


CURI13 (AS, AU, H) 
H AU>AS 
H AS >AS 
Claves: (H AU), (H AS) 
FN4 
CUR14 (AS, P, AL, C) 
AS AL>C 
Clave: (AS AL) 
No es FNBC ni FN4 
CURIS (AS, P) 
AS>P 
Clave: (AS) 
FN4 
CUR16 (AS, AL, C) 
AS AL>C 
Clave: (AS AL) 
FN4 


Hemos perdido en la descomposición las DFs (H P>AU) y (H AL>AU). El 
diseño obtenido es: 


CURI13 (AS, AU, H); CURIS (AS, P); CURI6 (AS, AL, C) 


Como hemos perdido DFs, este diseño podría generar filas inválidas al ayuntar. 
Por ejemplo: 


CUR 13 AS AU H 


Latín Aul 9-10 
Histor. Au2 9-10 


CURIS AS Pp 
Latín Pl 
Matem. P2 
Histor. Pl 


CURI16 AS AL C 
Latín All E 
Latín A12 A 
Histor. A13 S 
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La yunción de estas tres relaciones da: 


AS AU H PAL 


Latín Aul 9-10 Pl All 
Latín Aul 9-10 Pl Al2 
Histor. Au2 9-10 Pl A13 


n>m| Aa 


Vemos que en esta última relación no se cumple la DF (H, P>AAU) (en la relación 
parece que el profesor Pl estaría a la vez en el aula 1 y en la 2 a la misma hora, 
dando clases diferentes, una de Latín y la otra de Historia). 


Ejemplo 2: 
Supongamos que tenemos dos máquinas para fabricar tres tipos de productos, de 
modo que cada máquina puede fabricar varios de éstos, por ejemplo: 

e La máquina Ml] sirve para fabricar los productos P1 y P2. 

e La máquina M2 sirve para fabricar los productos P2 y P3. 


Cada empleado sólo sabe manejar una máquina. Por ejemplo: 
e El empleado El sabe utilizar la máquina M1. 


e El empleado E2 sabe utilizar la máquina M2. 
e El empleado E3 sabe utilizar la máquina M2. 


Podemos construir una relación, FABRICA, que indique qué productos puede 
fabricar cada empleado en cada máquina: FABRICA (E, M, P). (Atributos: 
Empleado, Máquina, Producto.) 


La extensión de esta relación en nuestro ejemplo será: 


FABRICA| E M E 


Las condiciones especificadas pueden representarse con las dependencias: E>M; 
M>P. 


Es decir, tenemos el esquema: 
FABRICA (E, M, P) 
E >M 
* M>P 
Clave: (E, P). 
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No es FNBC ni, por tanto, FN4. Normalicemos: 
FAB1I (M, P) 
Clave: (M, P) 
FN4 
FAB2 (E, M) 
E>M 
Clave: (E) 
FN4 


En el ejemplo dado las extensiones serían: 


FABI1 | M P FAB2 | E M 
MI Pl 
MI  P2 
M2  P2 
M2  P3 
Ejemplo 3: 


Supongamos ahora que en la relación anterior se cumple otra condición más: que 
cada empleado sólo sabe fabricar un tipo de producto. Tendríamos: 
FAB (E, M, P) 
E >M 
E >P 
M>»P Xx >» y 
Clave: (E). W 
De aquí se infiere la DF (M>.P) como sigue: 
M>»P; E>P; como E y P son disjuntos: M=>P. 
Es decir, la DP (M—>>P) es en realidad una DF. 
Tendremos pues: 
FAB (E, M, P) h => 1 
E >M ] 
* M>P Y 
Clave: (E) 
No es FNBC M 
Normalizando tendríamos; 
FAB3 (M, P) 
M>P 
Clave: (M) 
FNBC y FN4 
FABA4 (E, M) 
E>M 
Clave: (E) 
FNBC y FN4 
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Ejemplo 4: 


Supongamos ahora que en la relación anterior no se verifica ninguna DF, es decir, 
que un empleado puede usar varias máquinas y fabricar todos los tipos de 
productos que se puedan fabricar en esas máquinas. 


Tendríamos: 


FABRI (E, M, P) 
M>P 
Clave: (E, M, P) 
FNBC (no FN4) 
Por complementación: M>»E. 
Normalizando: 


FABRII (M, P) 
Clave: (M, P) 
FN4 


FABRI2 (E, M) 
Clave: (M, E) 
FN4 


Aparentemente han desaparecido las DPs originales, (M>P) y (M—E). No es 
así, porque son DPs triviales en FABRII y FABRI, respectivamente. Cualesquie- 
ra que sean las filas que insertemos en FABRIl y FABRI?, la yunción de éstas 
producirá una extensión válida de FABRI, pues al asociar todos los valores de P 
y E correspondientes a uno de M, se cumple M-—>P (y M>»E) en el resultado de 
la yunción. 


DEPENDENCIAS EMBEBIDAS 


En el último ejemplo anterior hemos visto que las DPs se han propagado al 
descomponer, aunque se han transformado en triviales. Pero, por otra parte, la 
DP (P>»M), que se verifica en FABRII (es trivial), no es válida en FABRI. 

Es decir, al descomponer una relación pueden aparecer DPs que no se 
verifican en la relación original. Si estas DPs son triviales, como la (P>»M) de 
FABRII, no importa, porque no suponen ninguna restricción, es decir, cualquier 
extensión las cumple. Si no son triviales, estamos en presencia de un nuevo tipo 
de condición de integridad que no es expresable como DF ni como DP, y que 
podría enunciarse diciendo que las tuplas de la relación original deben ser tales 
que se cumpla una determinada DP en el resultado obtenido al proyectarla. 
Esta situación no se puede presentar con DFs porque cualquier DF aplicable a 
una proyección lo es también a la relación original, y en cambio para las DPs 
puede no ser así. 


Con más precisión, sea una relación R, con dependencias DEPR. Sea S una 
proyección de R, y sea DEPS el conjunto de dependencias aplicable a S. 
Entonces: 


e Si (X>Y) está en DEPS+, también está en DEPR+. 
e Para DPs esto no es necesariamente cierto. 
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Al 


Además, al proyectar siempre hay alguna DP que no se transmite completa. 
En efecto, si X>Y se transmitiera completa, no se transmitiría completa su 
complementaria, X>»U-—Y. En definitiva, supongamos que la relación R, con 
dependencias DEPR, se descompone proyectándola en S y T, transmitiendo a 
éstas las dependencias DEPS y DEPT, respectivamente. Si tomamos dos exten- 
siones válidas de S y T, es decir que cumplan DEPS y DEPT, esto no implica 
en general que su yunción R=S * T cumpla las dependencias originales DEPR. 


Recuérdese, sin embargo, que para dos extensiones cualesquiera de S(A, B) 
y T(A, C), en su yunción S* T se verifica que A>B y A>C. 


Supongamos que al obtener S nos damos cuenta, de acuerdo con el significa- 
do de los atributos de S, de que existe una DP (X>>Y), aplicable a S y no trivial 
en S, que no es aplicable a R. Decimos en este caso que (X>Y) es una DP 
embebida en R, y explícita en la proyección S de R. 


Ejemplo: 


Tomemos la relación PREOQ siguiente, que indica los alumnos matriculados por 
asignatura, los prerrequisitos entre éstas y las fechas en que los estudiantes han 
aprobado los prerrequisitos. 
PREQ (AS, AL, PRE, F) 
AS: — Asignatura en la que el alumno está matriculado 


AL: Alumno 
PRE: Asignatura prerrequisito 
F: — Fecha en que aprobó el prerrequisito 


Ejemplo de extensión de PREQ: 


PREQ AS AL PRE F 


Esto significa que, por ejemplo, el Alumno All está matriculado en Física-2, 
aprobó Física-1 en 1983, aprobó Matemáticas-1 en 1983, y que tanto Física-1 
como Matemáticas-1 son asignaturas que hay que tener aprobadas antes de cursar 
Física-2. 
La única dependencia es (AL, PRE>+F). 
Tenemos pues el esquema: 
PREQ (AS, AL, PRE, F) 

AL PRE>F 

Clave: (AS, AL, PRE) 

No es FNBC 
Es evidente que en PREQ no se cumple la DP (AS—>AL), pues si tomamos dos 
filas con igual AS, por ejemplo: 


Fis2 A11 Fisl 1983 
Fis2 A12 Matl 1984 
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al intercambiar los alumnos entre ellas se obtienen tuplas que no están en 
la relación: 

Fis2 A12 Fisl 1983 

Fis2 A11 Matl 1984 


Esto se debe a que los alumnos pueden haber aprobado los prerrequisitos en años 
diferentes, como ocurre en el ejemplo. 


Descompongamos ahora PREQ para normalizar: 


PREQ1 (AL, PRE, F) 
AL PRE>F 
Clave: (AL, PRE) 
FNBC 


PREQ2 (AS, AL, PRE) 

Clave: (AS, AL, PRE) 

FNBC 
Aparentemente hemos llegado a un diseño correcto, normalizado y que preserva 
las dependencias. Sin embargo, de acuerdo con el significado de los atributos, es 
lógico imponer a las tuplas de PREQ2 la condición (AS>PRE), y por comple- 
mentación (AS—>AL), aunque, como ya hemos visto, no se cumplen estas condi- 
ciones en PREQ. Es decir, que tanto (AS>AL) como (AS>PRE), son DPs 
embebidas en PREQ, y explícitas en PREQ2. 


Si admitimos que AS>PRE es aplicable a PREQ2, entonces esta relación no es 
FN4. Normalicémosla: 
PREQ3 (AS, PRE) 
FN4 
PREQ4 (AS, AL) 
FN4 
Hemos llegado así al esquema de diseño: 
PREQ1 (AL, PRE, F); (Asignaturas aprobadas por los alumnos) 
PREQ3 (AS, PRE); (Prerrequisitos por asignatura) 
PREQ4 (AS, AL); (Alumnos matriculado por asignatura) 
En este diseño se debe cumplir una condición de integridad que no es expresable 


como DF ni DP. Es la siguiente: la proyección de PREQ1 sobre (AL, PRE) debe 
coincidir con la proyección de (PREQ3 + PREQ4) sobre los mismos atributos. 


Con los valores del ejemplo: 


PREQI | AL PRE E PREQ2 | AS PRE PREQ4 
All Fisl 1983 Fis2 Fisl Fis2 All 
All  Matl 1983 Fis2 Matl Fis2 A12 


A12 Fisl 1985 
Al2 Matl 1984 


En resumen, al normalizar hay que estar atento a si aparecen en algún caso, 
al proyectar, dependencias plurales no explícitas en la relación original, de 
acuerdo con el significado de los atributos. 
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Vamos a considerar ahora una nueva notación para DPs que puede usarse 
también para expresar las DPs embebidas. 


DEPENDENCIAS JERARQUICAS 


Hemos visto que si en una relación R(A, B, C) existe una DP (AB), 
también se verifica que (A>»C). Esto nos sugiere emplear la notación (A>»B | C), 
para indicar que ambas DPs de verifican. La existencia de estas dos DPs puede 
también interpretarse como la existencia de dos asociaciones independientes entre 
los valores de los atributos A y B, por una parte, y los de A y C por otra. Es 
decir, que a cada valor de A corresponden varios de B y varios de C, y que éstos 
son independientes de aquéllos. 


Ejemplo: 
En la relación FABRICA (E, M, P) estudiada anteriormente tenemos que una 
máquina puede ser usada por varios empleados para fabricar varios productos, y 


los productos que se pueden fabricar con ella son independientes de los empleados 
que la usan, es decir, (M-=>>P | E). 


Por otra parte, si volvemos a la relación PREQ (AS, AL, PRE, F), ya 
estudiada más arriba, vimos ya que las condiciones (AS>»AL) y (AS>>PRE) son 
DPs embebidas, es decir, que no se verifican en PREQ, pero si en la proyección 
de PREQ sobre (AS, AL, PRE). La nueva notación nos permite expresar esto 
más claramente. En efecto, si decimos que (AS>AL|PRE) se verifica en la 
relación PREQ, estamos ya indicando que se trata de dos DPs embebidas, 
puesto que no se mencionan todos los atributos de PREQ. En resumen, dos 
asociaciones independientes entre los valores de tres atributos disjuntos, A, B, y 
C, las representaremos como (A>»B|C), y equivalen a una pareja de DPs, 
explícitas o embebidas, según que (A, B, C) incluyan o no a todos los atributos 
de la relación, respectivamente. 


Estas ideas pueden generalizarse a más de dos asociaciones. Sea una relación 
R con atributos (posiblemente compuestos) X, Y,, Y», ..., Y, Z, disjuntos. Si 
existen asociaciones independientes entre los valores de (X, Y ,), (X, Y), ..., (X, 
Y ,), diremos que se verifica una Dependencia Plural Múltiple entre X y (Y ,, Y, 
..., Y). También llamaremos a este tipo de condiciones Dependencias Jerárqui- 
cas (DJs), y la representaremos: (X>Y | Y>|---|Y,). 


Si Z= (), es decir, si todos los atributos de R están incluidos en (X, Y ,, Y, 
.., Y,), se trata de una DJ explicita. En caso contrario diremos que es una DJ 
embebida o implícita en R, y explícita en la proyección de R sobre (X, Y,, Y», 
A): 


Vamos a repetir la definición de DJ para dar más precisión a la idea de 
asociaciones «independientes». Para abreviar, vamos a usar las notaciones 
siguientes, ya definidas anteriormente: 


e Proyección de R sobre unos atributos X, Y: R[X, Y]. O sea: 
R[X, Y] =P(X, Y) (R) 
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e Conjunto de todas las parejas de valores de X e Y asociados en R, para 
un determinado valor, x, del atributo X: R(x, Y). O sea: 


R(x, Y) =P(X, Y) (S(X=x) (R)) 
Definición: Diremos que existe una DJ, (X>>Y, | Y>|---| Y,), si para todo valor x 
del atributo X en la relación R se verifica: 
R(x, Y,, Mos ...s Y,)=R(x, Y )*R(, Y))*+---*R(x, 8) 
La propiedad de reversibilidad por yunción al descomponer mediante proyec- 


ciones que tenían las DPs es generalizable a las DJs, puesto que aquéllas son un 
caso particular de éstas. Así, sea una relación R con atributos disjuntos X, Y,, 


Y), ..., Y, que incluyen a todos los atributos de R. La condición necesaria y 
suficiente para que la descomposición de R en proyecciones sobre (X, Y,), (X, 
Y), ..., (X, Y,), sea reversible por yunción es que se verifique (X>>Y, | Y, | --- | Y). 


Vamos a demostrar que esta propiedad es cierta. Para ello utilizaremos las 
dos identidades siguientes: 


1) R(X, Y, Y>, ..., Y, )=(Unión de todas las relaciones de la forma 
R(x, Y,, Y,, ..., Y,), obtenidas para todos los valores, x, de X en 
R)= u (para todo x) (R(x, Y ,, Y», ..., Y,)) 


2) R[X, Y,]*R[X, Y,]x ---*R[X, Y, ]= 
= U (para todo x) (R(x, Y,))x*R(x, Y,)*R(x, Y3)+ ---*R(x, Y,)) 


En efecto, veamos que si se cumple (X>Y, | Y, | ---| Y), la yunción reproduce 
la relación R: 


R(X, Y ,, Y, ..., Y,)= U (para todo x) (R(x, Y,, Y», ..., Y, ))= U (para todo 
x) (R(x, Y ¡)=+R(x, Y>)+* ---*R(x, Y ,)) =R[X, Y,]+R[X, Y,]* ---*R[X, Y,]. 


Recíprocamente, si la yunción de las proyecciones reproduce a R, se cumple 
que (X>Y, | Y,|---| Y,). En efecto: 


R(X, Y, Y), ..., Y,)=R[X, Y¡]*R[X, Y,]x ---*R[X, Y,]; u (para todo x) 
(R(x, Y,, Y, ..., Y,))= U (para todo x) (R(x, Y ,)+R(x, Y ,) + ---*R(x, Y,,)). 
Los dos lados de esta igualdad expresan uniones de relaciones disjuntas. 
Para que sean iguales, deben serlo término a término. Es decir, para todo x: 


R(x, Y,, Y2, ..., Y, )=R(x, Y ¡)*R(x, Y,) x + *R(x, Y,). 


Se ha demostrado que no existe un sistema finito y completo de reglas de 
inferencia para DJs, aunque existen algunas reglas que pueden ayudarnos a 
deducir unas DJs de otras en algunos casos. Veamos algunas de estas reglas a 
título de ejemplo. 


1) Permutación: Si (X>Y | Y,|---| Y,), también se cumplen las DJs que se 
obtienen de ésta cambiando el orden de las Ys. 


2) Agrupamiento: Se pueden agrupar varias Ys en una. Es decir, si (X>>»Y , | Y, | 
:»* | Y), también se cumple, por ejemplo, (X>Y, Y, | Yy| ---| Y). 
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3) Supresión: Se puede suprimir una Y cualquiera. Es decir, si (X>Y, | Y, |---| Y), 
también se cumple, por ejemplo, (X>>Y, | Y | ---] Y,) 


4) Proyección: Si (X>Y ¡| Y>|---|Y,) y (Y, <Y;,), también se cumple que 
ARI Y] Yo). 


Puesto que una DJ explícita, (X>Y | Y, | ---| Y,), equivale a DPs: X>Y ,, 
X>Y>, ..., X>Y,, si X no es una superclave de R, ésta no será FN4, pero se 
podrá normalizar proyectando sobre (X Y), (X Y), ..., (X Y). 


DEPENDENCIAS YUNCIONALES 


Sean X,, X,, ..., X,, conjuntos de atributos de U. A la condición de que la 
descomposición de R proyectando sobre X,, X,, ..., X,, sea reversible por 
yunción le daremos un nombre especifico. La llamaremos Dependencia Yuncio- 
nal, y la representaremos como *(X,, X,, ..., X,). 


Dicho de otra forma, en un esquema de relación R se cumple la DY 
*(X,, X,, ..., X,) si todas sus extensiones se pueden reconstruir ayuntando las 
proyecciones sobre X,, X,, ..., X,. O sea, para todas las extensiones de R se 
cumple que: 


R=R[X;]* R[X)] * --- * R[X,] 


Evidentemente, para que se cumpla la condición anterior, todos los atributos 
de R deben estar contenidos en X, X,... X,. Es decir, debe ser (X, X,...X,)=U. 


En consecuencia, la condición *(X,, X,) puede escribirse también como 
(X>Y |Z), donde (X=X, A X,), (Y=X,-—X)) y (Z=X,-—Xj). 


Como ya vimos, la condición (X>Y|Z), con Z=U-—XY, equivalía a la 
siguiente: si hay en R dos tuplas con igual X, también existen las que se obtienen 
intercambiando los valores de Y. Expresemos esto con una notación más precisa. 
Sean t, y t, dos tuplas de R. Representemos con t,(X) el valor del atributo X 
en la tupla t,. La condición (X>Y |Z) puede entonces expresarse así: 


Si existen en R dos tuplas t, y t, tales que t, (X)=t,(X), entonces también existe 
una tupla t,, no necesariamnte distinta a t, o t,, tal que t¿)=t,(0)=t,00), 
t4¿(V) =t,(M), t3(Z)=t,(Z), o lo que es igual: t¿(XY) =t, (XY) y t,(XZ) =t,(XZ). 


Con nuestra notación de DYs esto se expresaría así: 


Si la condición *x(X,, X,) se cumple y existen dos tuplas t, y t, de R tales que 
t,¡(X, NX))=t,(X, NX), entonces también existe una tupla t, en R tal que 
t¿(X,)=t,(X,) y t,(X,)=t,(X)). 


Esto se puede generalizar como sigue. Si la condición *(X,, X,, ..., X,) se 
cumple, también se cumple la condición siguiente: 


Si existen, en R, n tuplas, t,, t,, ..., t,, tales que t(X,X)=t (X, n X ¡), para todo 


i y j de 1 a n, entonces también existe en R una tupla t, no necesariamente distinta 
de t,, t>, ..., t,, tal que t(X;)=t,(X;) y t(X¡) =t¡(X;). 
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Ejemplo: 
Supongamos que R(A, B, C, D, E) satisface la condición *(ABC, BD, CDE) 
Tenemos por tanto: X1=ABC, X2=BD, X3=CDE. Supongamos que R contiene 
las tuplas siguientes, entre otras: 

<a, ¡Divo das. > 

(al, b, c, d, e2> 

¿22 bliuetd, el> 
Pongámoslas en este orden: 

tada cb, Crd. e A ABE 

t,: (al, b, c, d, e2); X,=BD 

ta: (a2,bl;.c; d, el); .X5=GDE 
Vemos que: 

t,¡(X, OX2)=t2(X, NX2)=b 

t,¡(X, NX3)=t3(X, NX3)=C 

t¿(X, N X3)=t3(X, NX3)=d 

t,(X,)=<abc> 

t,(X2)=<bd)> 

t¿(X3)=<cdel> 
Por tanto, si se cumple la DY *(ABC, BD, CDE) en R, ésta deberá contener la 
tupla <a, b, c, d, el>. 
Si tomamos las tuplas anteriores en otro orden, tendríamos: 

t,: Cal, b, c, d, e2»; X, =ABC 

ta: Ca 0D, Cd, ¡85 .X>,=BD 

tz: (a2, bl, c, d, el); X3=CDE 
Vemos que: 

t,(X, N<X,)=t,(X, NX,)=b 

t¡(X, OX3)=t4(X, nX3)=cC 

t¿(X, 0 X3)=13(X, 0 X3)=d 

t,(X,)=<al bc) 

t,¿(X,)=<bd> 

t¿(X3)=<cdel)> 
Por tanto, si se cumple la DY *(ABC, BD, CDE) en R, ésta deberá contener la 
tupla <al, b, c, d, el). 


Como (X;,, X,,..., X,) debe contener todos los atributos de R, la condición 
anterior para DY puede enunciarse de la forma siguiente. Sean ty, tz, ..., tp, 
tuplas de R tales que en todas las combinaciones posibles dos a dos de ellas se 
verifica t,(X,  X;)=t,(X, N X;). Formemos ahora a una tupla t tal que t(X,)= 
t, (X,), t(X,)=t,(X,), t(X3) =1,(X3), ..., t(X,)=t,(X,). Una condición necesaria 
para que R cumpla la DY *(X,, X,, X;, ..., X,) es que, para todo grupo de n 
tuplas que exista en R con las condiciones anteriores, la tupla t que se obtiene 
de ellas como se ha indicado también esté en R. En el caso de n=2, esta 
condición es necesaria y suficiente. 
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En las definiciones de DY dadas, intrepretaremos que si (X,X;)=0, se 
cumple que t(X,0 X)=t¡(X,0X;). Si X,, X,, ..., X,, son disjuntos, todas las 
combinaciones posibles de sus valores existen en R. Por ejemplo, sea R(A, B, O), 
y sea (a, b) el conjunto de valores de R[A], (1, 2) el de R[B] y (m, n) el de R[C]. 
Entonces, la siguiente extensión de R cumple la DY *(A, B, C): 


RIA B 


Bajo 


TOO Op ppp 
MN Nm n= DN — . 
53535385 


Una DY es trivial si se verifica para todas las extensiones posibles de R, sin 
ninguna restricción. La condición necesaria y suficiente para que la DY 
*(X,, Xz, ..., X,) sea trivial es que alguno de sus componentes, tal que X,, 
incluya a todos los atributos de R (o sea, que X,=U). En caso de una DP, ya 
sabemos que toda DP trivial es, o bien de la forma X>-Y, donde Y <X, o bien 
de la forma X>»U—X. El primer caso equivale a la DY *(XY, XZ), con (Y <X) 
y (Z=U-—X), o sea, *x(X, U). El segundo caso es *x(XY, XZ), con (Y =U-—X) y 
(Z=U-—XY), o sea, *x(U, X). 


Cuando (X, X,X3...X,)=(U')<U, es decir, no incluye a todos los atributos 
de U, la DY se llama embebida en R, y será por el contrario explícita en la 
proyección de R sobre U'. Por tanto, esta proyección será descomponible 
proyectándola sobre X,, X,, ..., X,. 


Existen reglas de inferencia que permiten deducir unas DYs a partir de otras. 


Vamos a enunciar a título de ejemplo algunas reglas de inferencia para DYs. 
Sea un esquema R, con un conjunto U de atributos, y sean X,, X,, ..., pe 
subconjuntos de U tales que (X, X,...X,)=U. 


1) Permutabilidad. Si se verifica en una extensión de R la DY x(X,, X,, ..., 
X,), también se verifica cualquier DY que se obtenga de ésta cambiando 
el orden de las X. Esto es consecuencia de la conmutatividad del operador 
de yunción. 


2) Reflexividad. Si consideramos una DY con sólo un componente, éste debe 
ser U, es decir, se verifica *(U). 


3) Extensibilidad. Si se verifica en una extensión de R la DY X. Mda 
y X,, es un subconjunto de U, también se cumple + (X,, DE. 


4) Reagrupamiento. Si se verifica en una extensión de R la DY « 2 e 
...» X,), también se cumple x*((X, X>), X3, ..., X,) 


n/): 
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6) Proyección. Sea S el conjunto de todos los atributos que están en dos O 
más componentes X,, es decir, S contiene a (X,N X;) para todo 1, j. 
Evidentemente, X, n S, contiene a todos los atributos de X; que se repiten 
en algún X;,. Además, todos los atributos de U—S pertenecen a un solo 
componente. : 


Entonces, si se verifica en una extensión de R la DY O O 
X,), también se cumple la DY embebida *x(X, NS, X2N SIS): 


7) Substitución. Si se verifica en una extensión de R la DY *(X;,, X2, X3, 
..., X,) y la DY embebida *(Y ¡, Y >, .... Y m), Y además X, =(Y, Y... Y m), 
también se verifica la *(Y ,, Y», ...) Ym» X2, X3, +++» Xp). 


FORMA NORMAL DE PROYECCION-YUNCION 


Del mismo modo que las anomalías producidas por DPs desaparecían en la 
cuarta Forma Normal (FN4), las producidas por DYs pueden eliminarse trans- 
formando a una forma normal que suele designarse como quinta Forma Normal 
(FNS5), o también Forma Normal de Proyección-Yunción (FNPY). 


Recordemos las anomalías de actualización debidas a las DPs. Decíamos que 
si (A>»B) y A no es una superclave se pueden presentar anomalías de actualiza- 
ción. Dicho de otra forma, si A es una superclave, cuando actualizamos una 
extensión de R basta con tener en cuenta que no se viole la condición de que A 
es una superclave. No hace falta ninguna otra comprobación. Así, al añadir una 
nueva fila sólo hay que comprobar que el valor que tiene A no existe ya en 
alguna de las filas existentes. Una vez cumplida esta-cóndición, ya no hay que 
comprobar más, pues A>»B se cumplirá por añadidura. Es decir, diremos que 
no hay anomalías, y que un esquema de relación R está normalizado si todas 
las condiciones de integridad aplicables al esquema son inferibles a partir de sus 
claves. 


En resumen, definiremos la FNS como sigue: 


Sea un esquema de relación R, con un conjunto DEP de DFs y DYs. Diremos que 
R está en Forma Normal de Proyección-Yunción (FNPY o EN5) si todas las DFs 
y DYs no triviales aplicables al esquema R, son inferibles a partir de las claves de R. 


Una condición necesaria para que *(X,, X,, ..., X,) sea inferible de las claves, 
es que haya al menos una pareja de componentes cuya intersección, XA X;j, 
sea una superclave. Para n=2 esta condición es necesaria y suficiente. 
Comprobemos esto. 


En efecto, supongamos que *(X,, X», ..., Xy) €s aplicable a R y que ninguna 
combinación X, n X; de esta DY es superclave (o sea, que para todo i, j, O bien 
la intersección (X, A X;) es vacia (0D), O bien, si no es vacía, no contiene una 
clave). Representaremos con X;; a la intersección (X; A Xy). 


Sea una extensión de R formada por n tuplas, t,, t, ..., t,, construidas de la 
forma siguiente: 
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1) t, tiene valores cualesquiera. 


2) t, tiene en X,, los mismos valores que t, (si X,, no es ())), y el resto son 
todos diferentes,uno a uno, a los de t,. 


3) tz tiene en X,3 los mismos valores que t,, y en X,3 los mismos que 
t,, y en el resto diferentes, uno a uno, que los de t, y t,. 


4) Etc. 


Este grupo de n tuplas cumple dos a dos que t,(X;¡)=1;(X;¡), y todos los 
demás valores son diferentes, por lo que cumple que los atributos de las claves 
no toman valores repetidos. Por otra parte, la tupla t, tal que t(X;)=t;(X;) para 
todo i, no está en esta extensión de R, luego no se cumple en ésta la *(X,, X>, 
==> X,). Es decir, hemos construido una extensión de R que satisface la unicidad 
de las claves, pero no la DY, por lo tanto ésta no es inferible de las claves. Dicho 
de otra forma, para toda DY inferible de las claves es imposible que todas sus 
X;, sean no superclaves. O, lo que es igual, para toda DY inferible de las claves, 
alguna X;, es no vacía y es una superclave. 


Esta propiedad permite construir un algoritmo para determinar si una DY 
dada es inferible de las claves. El algoritmo, debido a Fagin, se basa en aplicar 
iterativamente esta propiedad y la de reagrupamiento. Si consideramos una 
DY *(X,, Xz, ..., X,) que sea inferible de las claves, tendrá una pareja de 
componentes cuya intersección sea superclave. Sean X, y X, estos componentes. 
Aplicando la regla de reagrupamiento se deduce la DY *(X, X,), AR y a) 
que, puesto que se infiere de la DY dada, también es inferible de las claves, y se 
le puede aplicar el mismo proceso. Repitiendo este proceso se llegará a la 
DY x*(X, X>...X,), es decir, *(U). Por tanto, si la DY dada es inferible de las 
claves, al ir reagrupando se llega a *(U). Puede demostrarse que el recíproco 
también es cierto. En definitiva, sí se llega a «(U) la DY es inferible de las claves 
y en caso contrario no lo es. 


Obviamente, si R está en FNS también está en FN4, pero no necesariamente 
al revés. 


FORMAS NORMALES EN GENERAL 


En cierto sentido, la FNS es la forma normal «definitiva». No puede haber 
más tipos de formas normales sobre condiciones de integridad basadas en 
operaciones de (Proyección-Yunción). Sin embargo, el camino seguido para 
definir la FNS se puede generalizar a otros tipos de condiciones de integridad 
Antes de hacerlo, vamos a justificarlo, viendo que es aplicable asimismo a las 
definiciones de FNBC y FN4, 


Consideremos primero la definición de FNBC. Dijimos que un esquema de 
relación, R, está en FNBC si para toda DF no trivial de DF +, el antecedente 
es una superclave. Vamos a justificar que esto es equivalente a decir que esta 
DF es inferible de las claves. 
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Sea un esquema R y un conjunto de DFs, DF, aplicables a R. Sean K,, K,, 
.., K,,, las claves de R. 


1) 


2) 


Si R está en FNBC., todas sus DFs no triviales son inferibles de las claves. 


En efecto, si R está en FNBC, en toda DF no trivial, tal que X>Y, 
aplicable a R, se cumple que X contiene a una clave al menos, por ejemplo 
a K,, es decir, X>K;,. Por tanto, X>K;,, y como K,>Y, resulta que 
X > Y. Es decir, toda DF es inferible a partir de las claves. 


Si todas las DFs son inferibles de las claves, R está en FNBC. 


En efecto, sea X>Y una DF no trivial aplicable a R en la que X 
no es una superclave. Consideremos una extensión de R formada por las 
tuplas: 


(Xy 121), 
(XY2Z2), 


(donde todos los elementos de y, son diferentes a los de y,, y los de z, a 
los de z)). 


Esta extensión satisface las claves porque, al no ser X una superclave, 
todas las claves están contenidas en (YZ). Pero como <y,Z,> y <y2Z2> son 
distintos en todos los atributos, las claves no se repiten. En definitiva, esta 
extensión de R satisface las condiciones de las claves. Sin embargo, no 
cumple X>Y. Luego esta DF no es inferible de las claves (pues una 
condición de integridad es inferible de otras, por definición, cuando toda 
extensión que satisface a éstas también satisface a aquélla). 


En resumen, si todas las DFs no triviales aplicables a R son inferibles 
de las claves, sus antecedentes son superclaves, y por tanto R está en 
FNBC. : 


Veamos ahora la definición de FN4. Dijimos que un esquema de relación, 
R, está en FN4 si para toda DP no trivial de DP+ el antecedente es una 
superclave. Vamos a justificar que esto es equivalente a decir que esta DP es 
inferible de las claves, para lo cual seguiremos el mismo método que más arriba. 


Sea un esquema R y un conjunto de DFs y DPs, aplicables a R. Sean 
Ki, Ko, :525 8 Las. claves de K. 


1) 


2) 


Si R está en FN4. todas sus DPs no triviales son inferibles de las 
claves. 


En efecto, si R está en FN4, en toda DP no trivial, tal que X>Y, 
aplicable a R, se cumple que X contiene a una clave al menos, por ejemplo 
a K,, es decir, X>K;,. Por tanto, X>K,, y como K,>Y, resulta que 
X> Y, y en consecuencia, X>Y. Es decir, toda DP es inferible a partir 
de las claves. 


Si todas las DPs son inferibles de las claves, R está en FN4. 
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En efecto, sea X>Y una DP no trivial aplicable a R en la que X 
no es una superclave. Consideremos una extensión de R formada por las 
tuplas: 


(Xy ¡ Z1) 
(XY2Z2>, 


(donde todos los elementos de y, son diferentes a los de y», y los 
de z, a los de z,). 


Esta extensión satisface las claves, como ya vimos anteriormente. Sin 
embargo, no cumple X>Y. Luego esta DP no es inferible de las claves. 


En resumen, si todas las DPs no triviales aplicables a R son inferibles de 
las claves, sus antecedentes son superclaves. 


En general, dado un tipo, CI, de condiciones de integridad cualesquiera, 
podemos definir una Forma Normal para las condiciones Cl, y la representare- 
mos FN-CI, de la forma siguiente: 


Un esquema R de la relación está en FN-CI si todas las condiciones de tipo CI no 
triviales aplicables a R son inferibles de las clayes de R. 


Así es para las Formas Normales definidas hasta ahora: 


Tipo de Cls Forma Normal 
DFs FNBC 
DPs y DFs FN4 

DYs y DFs FNPY 


Por tanto, si un esquema de diseño está normalizado, el Sistema de Gestión 
de Bases de Datos (SGBD) sólo necesita comprobar, cada vez que se actualiza 
una relación, que los atributos que son claves no toman valores repetidos. No 
necesita hacer comprobaciones adicionales, pues todas las restantes condiciones 
de integridad se cumplirán automáticamente por ser consecuencia de las claves. 
En definitiva, el SGBD sólo necesita estar dotado de mecanismos que le permitan 
asegurar la unicidad de los valores de las claves. 


NORMALIZAR O DESNORMALIZAR 


Dado un esquema de diseño formado por varios esquemas de relación, R,, 
R), ..., R,, y un conjunto de dependencias, habrá en general algunos de ellos 
normalizados y otros no, y los normalizados lo estarán a distinto grado (FN3, 
FNBC, etc.). Podemos preguntarnos si es conveniente normalizar todos los 
esquemas y hasta qué grado. Esta pregunta debe responderla el analista o 
diseñador en cada caso particular, aunque deberá tener en cuenta algunas 
consideraciones de tipo general como las siguientes: 


e Cuanto mayor sea la normalización más fielmente se representa el mundo 
real en el esquema y, por tanto, el diseño será probablemente más estable. 
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e Si se normaliza al máximo, ni el sistema ni los programas deben responsa- 
bilizarse, para proteger la integridad de los datos, de otra cosa que de la 
unicidad de valores de las claves. Esto disminuye los riesgos de integridad 
y la redundancia, y por consiguiente mejora el rendimiento en operaciones 
de actualización. 


e Por el contrario, una mayor normalización suele implicar un número 
también mayor de relaciones (más pequeñas, o sea, con menos atributos 
cada una). Esto puede obligar a un incremento en el número de operacio- 
nes de yunción, con lo que el rendimiento en consultas puede ser peor. 


En conclusión, es conveniente normalizar, como directriz general de diseño, 
aunque puede haber excepciones por razones de rendimiento o facilidad de uso 
en consultas. 


DEPENDENCIAS GENERALIZADAS 


Vamos a introducir una nueva notación para expresar las DFs, DPs y DY's 
que nos permitirá generalizar el concepto de dependencia. 


Recordemos la definición de DF. Si tenemos un esquema de relación, por 
ejemplo R(A, B, C, D), decimos que R cumple la DF A>B si para toda 
extensión válida de R se verifica que si dos tuplas tienen iguales valores en A, 
también son iguales sus valores en B. O, dicho de otra forma, si hay en R dos 
tuplas tales como <a bl cl d1> y <ab2c2d2>», debe ser bl =b2. Esto lo podemos 
representar con una notación tabular de la forma siguiente: 


a bl cl dl 
a b2 c2 d2 


bl =b2 


Las filas por encima de la raya se llaman hipótesis, y la que está debajo se 
llama conclusión. 


Consideremos ahora la condición A>»B. Si se cumple, quiere decir que si hay 
en R dos tuplas con iguales valores en A, también están en R las que se obtienen 
intercambiando los valores de B. Es decir, si hay en R dos tuplas tales como 
(ablcld1> y <ab2c2d2», también debe estar en R la tupla <abl1c2d2) (no 
hace falta expresar que también esté la <ab2c1 dl)», pues ésta se deduce de la 
condición simplemente considerando las tuplas de partida en distinto orden). 
Esto lo podemos expresar como antes en forma de dos hipótesis y una conclu- 
sión: 

a b1.,vel.. di 
a b2 02, d2 


a bl c2 d2 


Pueden dejarse en blanco los valores que sólo figuran una vez. Por ejemplo, 
la notación anterior para expresar A>B podría quedar así: 
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a 


a b E 


Consideremos ahora la DY *(AB, BC, CD). Si esta DY se cumple en R, 
quiere decir que para todo grupo de 3 tuplas de R de la forma (abel dl», 
<a2bcd2> y <a3b3cd», también debe existir en R la tupla <abed)». Con 
nuestra notación tabular: 


A B (E D 


b ap del 

2d b c Ese 
—= Cc d 

a b e d 


Por convenio, un símbolo no puede aparecer más que en una columna (tanto 
si es un símbolo de las hipótesis como de la conclusión), pero puede repetirse 
dentro de su columna. Puede haber símbolos en la conclusión que no aparezcan 
en las hipótesis. Estos símbolos los llamaremos singulares. 


Vemos que hay dos tipos de conclusiones: o bien una igualdad entre 
simbolos no singulares, o bien una tupla. 


A las condiciones de integridad expresadas mediante esta notación, las 
llamaremos Dependencias Generalizadas (DGs). Si todos los símbolos de la 
conclusión aparecen en las hipótesis (es decir, si no hay símbolos singulares), 
diremos que es una Dependencia explícita. En caso contrario diremos que es 
implícita o embebida. Así, por ejemplo, en el esquema RÍA, B, C, D), la DP 
embebida A>B|C, se representa como: 


A B € D 


dl 
a b2 d2 


a b C d3 


p 
[ej 
o 


O también: 
A B € D 


a b = — 
a — a > 


a b fo — 


Diremos que una extensión de R cumple una DG dada si, para toda 
substitución de los símbolos por valores tales que las hipótesis sean tuplas 
existentes en R, se verifica la igualdad expresada en la conclusión (si ésta es una 
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igualdad), o se verifica que la tupla de la conclusión también existe en R (es 
decir, que existe en R una tupla que coincide con la conclusión en los símbolos 
no singulares). 


Ejemplo: 
Sea la extensión R: 


R A B E 
0 1 2 
0 3 4 
0 3 2 
5 1 - 


Y sea la DG embebida: 


A B 5 
a b cl 
a b2 Cc 
a3 b c 


Vamos a comprobar que la relación R anterior cumple esta DG. Para ello 
tenemos que ver que para toda substitución posible de valores de a, b, c, a3, b2 
y cl, tal que las hipótesis estén en R, también la conclusión está en R. 


Consideremos primero una substitución de valores tal que las dos hipótesis 
produzcan la misma tupla de R. Por ejemplo, a=0, b=1, cl=2, b2=1, c=2; la 
conclusión será (a3 1 2)»; vemos que esta tupla existe en R para a3=0. En general, 
si (abcl) y (ab2c> representan la misma tupla de R, deberá ser b2=b y cl =c, 
con lo que abc» estará en R. Además la conclusión será (a3bc), que eviden- 
temente, si a3=a, existe en R. 


Consideremos ahora substituciones tales que las hipótesis correspondan a dos 
tuplas diferentes de R. Como ambas tuplas tienen el mismo valor de A, deberá 
ser a=0. Hay, pues, tres posibles substituciones: 


Substitución .a b cl b2 cc Conclusión  a3 
1 0. “1 2 3 4 (a314> 5 
2 071 2 3 2 -<al2> 0 
3 AA: 4 3 2 (a332> 0 


Vemos pues que se cumple en R la DG mencionada. 


Análogamente a como hicimos con los otros tipos de dependencias, podría- 


mos definir que un esquema de relación está normalizado para DGs si todas 
las DGs no triviales son inferibles a partir de las claves. Sin embargo, este 
concepto no suele utilizarse, pues es dificil de manejar. La mayor utilidad de las 
DGs es que sirven de base a un algoritmo para deducir si una DG dada es 
inferible de otras, al que llamaremos algoritmo de Batida. 
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Antes de pasar a describir este algoritmo vamos a definir una operación que 
llamaremos «aplicación» de una DG a una relación. Sea d una DG y sea R una 
extensión de un esquema de relación. Supongamos que encontramos una substi- 
tución de los símbolos de las hipótesis de d por valores tales que todas ellas 
resultan ser tuplas existentes en R. Si la conclusión de d es una igualdad, la 
aplicación de d a R consiste en igualar en R todos los valores asociados a los 
símbolos que se igualan en la conclusión. Para ello, basta subtituir uno cualquie- 
ra de ellos por el otro en todos los de R en que aparezca. 


Si la conclusión de d es una tupla que no tiene simbolos singulares, la 
aplicación de d a R consiste en añadir a R la tupla obtenida al substituir todos 
los símbolos de la conclusión por sus valores correspondientes. 


Si la conclusión de d es una tupla con símbolos singulares, la aplicación de 
d a R consiste en añadir a R la tupla obtenida substituyendo en la conclusión 
los símbolos no singulares por sus correspondientes valores, y los singulares por 
valores cualesquiera que no existan en otras tuplas de R. Si estos valores 
pudieran subtituirse por otros ya existentes en R de manera que la nueva tupla 
ya existiera completa en R, no se añadirá nada a R. 


Ejemplo 1: 
Aplicación de una DF a una extensión R. 


an 


1 
1 
2 


Rhhn]|u 
uuu lid 


b1=b2 


Substitución de valores: a=1, b1=2, cl =3, b2=4, c2=5. 
Resultado de aplicar d a R para esta substitución de valores: b2.=b1=2. 
Queda: 


Ejemplo 2: 


Aplicación de una DP a una extensión R. 


RA. ABRE 
[AD ES 
1.4 5 
2.4 3 
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Substitución de valores: a=1, b1=2, cl=3, b2=4, c2=5. Tupla de conclusión: 
(125). 


Resultado de aplicar d a R para esta substitución de valores: 


Si consideramos ahora la substitución de valores: a=1, b1=4, cUi<S: b2=2, 
c2=3, la tupla de conclusión será <143)», y el resultado de aplicar d a R' será: 


Cualquier otra substitución de valores que consideremos no nos permitirá ya 
aplicar d a R” de forma que R” cambie. Esto significa, con otras palabras, que 
para todas las substituciones posibles de valores tales que las hipótesis de d 
pertenezcan a R”, la conclusión de d también existe en R”. O, lo que es igual, R” 
satisface la condición expresada por la DG d. 


En general, la aplicación reiterativa de una DG, d. a una relación R, hasta que 


la relación ya no cambie, transforma a R en otra relación en la que se verifica la 
DG d. 


Ejemplo 3: 
Aplicación de una DP embebida: 


Ri: CASE B "E 2D d AMB e D 
a E a “"bife*citeudl 
lat 5 $ a JB. *c2 ud) 


Substitución: a=1, b1=2, cl=3, dl=6, b2=4, c2=5, d2=38. Tupla de conclu- 
sión: X125x>. 


Aplicación de d a R: 


RAAJOB CD 
II" 2430 0 
A 8 
LN 
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Consideremos otra substitución: a=1, b1=4, cl=5, dl =8, b2=2, c2=3, d2=6. 
La tupla de conclusión será <143 y)», y el resultado de aplicar d a R' será: 


Cualquier otra substitución no hace ya cambiar a R”. Consideremos, por ejemplo: 
a=1, b1=4, cl=5, dl =8, b2=2, c2=5, d2=x. La tupla de conclusión será: 
(145z)>. Vemos que para z=8 se obtiene una tupla ya existente. Por tanto, no 
se añade nada a R” y ésta queda igual. 


LA BATIDA 


Vamos a describir aquí el algoritmo para averiguar si una DG dada es 
consecuencia de otras. Lo llamaremos Algoritmo de Batida («Chase Algorithm»). 


Supongamos que tenemos un esquema de relación R en el que se verifica un 
conjunto, DG, de Dependencias Generalizadas: 


DG=(dí d, di, :.., d,) 


El Algoritmo de Batida tiene por objetivo averiguar si otra Dependencia 
Generalizada dada, d, es inferible del conjunto DG. 


Como ya hemos dicho anteriormente, d es inferible de DG si, y sólo si, todas 
las extensiones de R que cumplan DG, cumplen también la DG d. 


Veamos una descripción intuitiva de la idea en que se basa el algoritmo. De 
acuerdo con la notación empleada para una DG, si consideramos sólo las tuplas 
hipótesis de d, nos queda un conjunto de tuplas formadas con símbolos que 
puede considerarse como una relación, r, que es una extensión del esquema R. 


Tomemos la DG d, y apliquémosla a r reiteradamente hasta obtener una 
relación, r,, que ya no cambie más. Evidentemente, r, satisface la condición 
expresada por la DG d,. Apliquemos ahora (d,, d,, ..., d,, d,) repetidamente 
hasta llegar a una relación, r,, que ya no cambie más. Esta relación satisface al 
conjunto de condiciones DG. 


Supongamos que la conclusión de d es una tupla, t, que no está en r,. Dicho 
de otra forma, r, es una extensión de R que satisface todas las DG, pero no 
satisface la condición d. Por tanto, d no es inferible de DG. Por el contrario, 
puede demostrarse que si t está en r,, r, es una extensión de R que cumple tanto 
DG como d. 


Basándose en estas ideas se construye el Algoritmo de Batida, que consiste 
en lo siguiente. 
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Algoritmo de Batida 


1) Considerar la extensión, r, de R, formada por las hipótesis de d. 
2) Aplicarle las Dependencias de DG, en cualquier orden, hasta que: 
2.1) O bien ya no cambia más. 


2.2) O bien, si la conclusión de d es una tupla sin símbolos singulares, esta 
tupla existe en r, o bien, si la conclusión tiene algunos símbolos 
singulares, existe en r alguna tupla que coincide con t en todos sus 
símbolos no singulares. 


2.3) O bien, si la conclusión de d es una igualdad de valores, éstos se han 
igualado ya en r. 
3) Si nos paramos en el punto 2.1) anterior, d no es inferible de GD. Si nos 
paramos en los puntos 2.2) ó 2.3) anteriores, sí es inferible. 


Este procedimiento es finito si todas las dependencias de DG son explícitas, 
aunque crece exponencialmente con el número de dependencias. Además, si en 
DG hay alguna dependencia embebida, no es seguro que sea finito (es decir, no 
es un algoritmo). Sin embargo, si aún en este caso llega a pararse en algún 
momento, el resultado que produce es válido. Si DG está formado por DFs y 
DPs exclusivamente es más eficiente aplicar algoritmos basados en las reglas de 
inferencia que el Algoritmo de Batida. No hay algoritmo conocido que permita 
resolver este problema si DG incluye, por ejemplo, DPs embebidas. 


Veamos unos ejemplos de aplicación del Algoritmo de Batida. 


Ejemplo 1: 
Sea el esquema R(A, B, C, D), en el que se cumplen las DGs: 
DG: 

A>B|C 

BD 


Sea d: A>C|D 
Vamos a demostrar que d es inferible de DG. 


Expresemos las DGs en notación tabular: 


A>B|C: alo. DIAL Gl. dl 
al” b2 402... 002 


ale. bl cz. “d3 


B>D: ad b4 c4 d4 
a5 b4 c5 d5 
d4=d5 


A>C!|D: a6. s:b6. .¿có'  “d6 
a6  b7 c7 d7 


a6 b8 c6 d/ 
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Obtenemos r prescindiendo de la conclusión de d: 


36:.b6.'c6 d6 
26. ¿0% c7 d7 


Apliquemos a r la DG A>B|C: 


Vemos que la tupla de la conclusión de d, <a6b8c6d7», coincide con la 
(a6b7c6d7>», que está en r”, en todos los simbolos menos el que es singular (b8). 
Por tanto, d es inferible de DG. 


Ejemplo 2: 


Vamos a usar el Algoritmo de Batida para demostrar que si todas las DPs 
aplicables a R son inferibles de sus claves, entonces R es FN4 (ya hemos 
demostrado esto anteriormente). 


Sea, en efecto, una DP cualquiera, X»Y, aplicable a R, no trivial, con X e Y 
disjuntos, y en la que X no es una superclave. Vamos a demostrar que, en este 
caso, X>Y no es inferible de las claves. 


Sean K,, K,. ..., K,, las claves de R, o sea que se cumple: 
K,>U, K,>U, ..., K,>U 


Sea Z=U-—XY. Como X no es una superclave, todas las claves tienen que tener 
algún atributo en YZ, es decir, para todo i, K¡a YZ=0. 


Expresemos X>Y en notación tabular: 


Xx Y Z 


X1 Yi Z1 
Xi Y2 Za 


Xi Ya Zi 
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Partimos de: 


X1 Y2 Z) 


Apliquemos la DF K,>U a r. Como K, tiene algún componente en (YZ) y (y,z,) 
tiene todos sus elementos distintos a (y,z>,), la aplicación de K,>U no produce 
ningún cambio en r. Lo mismo pasa para K,>U, ..., K,>U. Por tanto, el 
algoritmo termina, y vemos que el resultado, r, no incluye ninguna tupla igual a 
la conclusión de X>Y. Luego esta DP no es inferible de las claves. Esto significa 
que si todas las DPs son inferibles de las claves, R tiene que estar en FN4, pues 
si así no fuera, habría alguna X>Y en la que X no sería superclave, y por tanto 
no podría ser inferible de las claves, lo que contradice la hipótesis de partida. 


EJERCICIOS PROPUESTOS 


1) Sea el esquema R(A, B, C, D, E) con las dependencias: 
A>BC; BC>A; BCD>E; E>C 
Normalizar R en FNBC. 


) 
— 


Sean los atributos A (Agente), O (Oficina), I (Inversor), V (Clase de valor), N 
(Nominal) y D (Dividendo), y el esquema de relación R(A, O, I, V, N, D), con 
las siguientes dependencias: 


V>D; I>A; IV>N; A>0 
Normalizar R en FNBC. 


3) Sea el esquema R(A, B, C, D) con las dependencias: 
AB>D; C>D; AB>C; C>B 
a) Normalizar R en FN3. ¿Se preservan las dependencias? 
b) Normalizar R en FNBC. ¿Se preservan las dependencias? 
c) Aplicar a R el algoritmo de descomposición que preserva dependencias. Compro- 


bar que se obtienen relaciones FN3. 


4 


— 


Sea el esquema R(A, B, C, D, E) con las dependencias: 
A=>BCDE; CD>E; CE>B. 


Normalizar R en FNBC. ¿Se preservan las dependencias? 
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5) 


6) 


8) 


9) 


10) 


11) 


Sea el esquema R(A, B, C, D, E, F) con las dependencias: 
DE>C; C>F; F>D; CE>A; EF>B 
a) Normalizar R en FNBC. ¿Se preservan las dependencias? 


b) Normalizar R en FN3. ¿Se preservan las dependencias?” 


Sea el esquema R(A, B, C, D, E) con las dependencias: 
C>A; A>BC; BCD>E; E>C 
a) Normalizar R en FNBC. ¿Se preservan las dependencias? 


b) Normalizar R en FN3. ¿Se preservan las dependencias? 


c) Aplicar a R el algoritmo de descomposición que preserva dependencias. Compro- 
bar que se obtienen relaciones FN3. 


Añadir a la relación siguiente las filas necesarias para que se cumplan en ella las DPs: 
A>BC; CD>BE: 


AB EA 
a dae 
a CN y e 
3 bb ucmide, id 


Sea el esquema R(A, B, C, D, E) con las dependencias: 
A>BC; DE>C 
Demostrar que AD>BE 


En el esquema del ejercicio 2 anterior queremos guardar la historia de los dividendos de 
cada tipo de valor. Entonces, en vez de cumplirse V>D, tendremos V>D. 


Normalizar R en FN4. ¿Se preservan las dependencias? 


Sea el esquema R(A, B, C, D, E, F) con las dependencias: 
A>BCD; B>AC; C>D 


Normalizar R en FN4. ¿Se preservan las dependencias? 


Sea el esquema R(A, B, C, D, E) con las dependencias: 
A>BC; D>C 
a) Demostrar que A>C. 


b) Normalizar R en FN4. ¿Se pierden dependencias? 
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al 


12) 


uy 
= 


14 


Y 


15 


pa 


16) 


17) 


18) 


Sea la siguiente extensión de R(A, B, C): 


A BE 
a 1 A 
a 2 B 
Dl. 3 "€ 
OS O Do. 
d 4 E 
ES” ME 


a) ¿Satisface esta extensión de R la DY: *(AB, AC, BC)? 

b) Añadimos a esta extensión la fila <f1 B). Añadir las filas que sean necesarias para 
que se siga cumpliendo la DY anterior. 

Sea el esquema R(A, B, C, D, E) con las dependencias: 

AB>C; C>E; E>C; C>D; AB>E 

a) ¿Está R en FNBC? 


b) Descomponemos R por proyecciones en R1(A, B, C), R2(A, D, E) YIRS(C, E): 
¿Es esta descomposición reversible por yunción? 


c) ¿Preserva las dependencias? 
d) Normalizar R1, R2 y R3 en FNBC. 


Sea el esquema R(A, B, C, D, E) con las dependencias: 

A>C; B>C; C>D; DE>C; CE>A; *(AD, AB, BE, CDE, AE) 
a) Hallar las claves. 

b) ¿Es la DY inferible de las DFs? 

Cc) ¿Es la DY inferible de las claves? 

d) ¿Está R en FNS5? 


Sea el esquema R(A, B, C, D, E) con las claves: 

K,: (BCE); K,: (ABE) 

Decir si son inferibles de las claves las DYs siguientes: 

a) «(ABCE, BCDE). 

b) k(ABCE, BDE, ACD). 

c) *(ABCE, BCE, ABDE). 

En el esquema del ejercicio 2 anterior descomponemos R por proyecciones en R1(V, D), 
R2(1, A), R3(1, V, D) y R4(4, 0). ¿Es esta descomposición reversible por yunción? 


En el esquema del ejercicio 2 anterior descomponemos R por proyecciones en R1(1, V, N), 
R2(1, A), R3(V, D) y R4(1, V, O). ¿Es esta descomposición reversible por yunción? 
¿Preserva las dependencias? 


Sea el esquema R(A, B, C, D, E). Los atributos (ABC) y (ABD) toman valores que 
no se repiten (es decir, son claves o superclaves). Además, se verifica AB>>C. Hallar 
una clave de R. 
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19) Sea el esquema de relación MATRIM (H, M, S, FB, FD), con el significado siguiente: 
En MATRIM hay una fila por cada matrimonio celebrado en el país desde 1970. 


Atributo H: Nombre del marido. Se supone que no hay personas diferentes con igual 
nombre. 


Atributo M: Nombre de la mujer. 
Atributo S: Situación del matrimonio. Puede ser una de las siguientes: 
e C: Casados todavía. 
e D: Ya divorciados. 
e S: Separados. 
e F: Alguno de los cónyuges, o ambos, han fallecido. 
Atributo FB: Fecha de la boda. 


Atributo FD: Fecha de disolución del matrimonio, bien por separación o divorcio, 
bien por fallecimiento de uno o ambos cónyuges. 


Enunciar las condiciones de integridad que lógicamente deberán cumplir todas las 
extensiones válidas de MATRIM. 
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DIAGRAMAS PARA AYUDAR EN EL DISEÑO 


Para diseñar un esquema de BD podríamos partir de un conjunto inicial de 
esquemas de relación, expresar las dependencias que se presentan entre sus 
atributos y someter este esquema a un proceso de normalización, según se ha 
visto en anteriores capítulos. Sin embargo, este proceso no proporciona criterios 
para formular, a priori, el conjunto inicial de esquemas más adecuado para llegar 
a un buen diseño. 


Además, según hemos visto, los algoritmos de normalización pueden ser de 
ejecución costosa y, según el orden seguido en el proceso, puede llegarse a 
distintos resultados. Todo ello hace que sea útil en la práctica emplear métodos 
más intuitivos, apoyados en representaciones gráficas, que ayuden a expresar y 
comprender más fácilmente-las interrelaciones entre los datos y apoyen el proceso 
de normalización. 


En el presente capítulo y en el siguiente vamos a proponer un método gráfico, 
basado en una mezcla de los modelos de datos binario y de Entidad/Asociación. 
La finalidad de combinar ambos modelos es manejar un concepto de entidad 
que sea lo más objetivo posible. En un modelo de Entidad/Asociación (Entity/- 
Relationship) hay que definir las entidades que se van a considerar en el modelo, 
lo que suele plantear dificultades para los usuarios que participen en el diseño 
y que no siempre están habituados a manejar estos conceptos. En el proceso 
propuesto, por el contrario, no es necesario predefinir las entidades, pues éstas 
se pueden obtener como un subproducto del proceso, sirviendo éste de apoyo y 
guía a la experiencia e intuición del diseñador. Sin embargo, el proceso también 
es aplicable si se le dan predefinidas algunas entidades, o todas, lo que permite 
acortar el trabajo a los diseñadores con experiencia. 


El método parte de la definición de conjuntos de datos, elementales o 
compuestos, y de su representación en un diagrama. A éste se le aplican unas 
transformaciones que permiten ir obteniendo relaciones más complejas, por lo 
que podríamos decir que se sigue un metódo de síntesis. Por el contrario, los 
procesos de normalización descritos en el capítulo anterior siguen un método 
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analítico en sentido inverso, partiendo de relaciones complejas y descomponién- 
dolas en otras más simples. 


Para transformar el diagrama hay que analizar antes algunas propiedades de 
algunos tipos de condiciones de integridad entre relaciones, que completen a las 
condiciones de integridad intrarrelación estudiadas en capítulos precedentes 
(dependencias funcionales, plurales, etc.). A esto se dedica parte de la materia 
del presente capítulo, en el que también vamos a describir cómo construir y 
transformar estos diagramas hasta llegar a definir las entidades y el esquema de 
diseño. 


Este capitulo está estructurado gradualmente, introduciendo cada nuevo 
concepto después de plantear el problema que se pretende resolver con él. Esto 
puede hacer la presentación algo redundante. El lector que desee ganar tiempo 
en una segunda lectura o repaso puede centrarse en los párrafos siguientes: 
Representación de conjuntos de valores. 

Representación de asociaciones binarias implícitas. 
Asociaciones implicitas entre relaciones unarias. 
Asociaciones implícitas entre relaciones n-arias. 
Regla de definición de claves. 

Regla de agregación de rectángulos. 

Regla de supresión de rectángulos. 

Representación de asociaciones n-arias. 
Asociaciones explícitas parciales. 

Producto de asociaciones. 

Dependencias plurales. 


Otros tipos de dependencias. 


En el capítulo siguiente se resume el método de diseño propuesto y se 
presentan algunos ejemplos. 


REPRESENTACION DE CONJUNTOS DE VALORES 


Empezaremos representango gráficamente conjuntos de valores simples, es 
decir, conjuntos de símbolos que tienen un cierto significado, definido porque 
cumplen una cierta propiedad o predicado. Este conjunto es una relación unaria, 
R(X), donde el nombre de la relación, R, es normalmente una abreviatura de la 
propiedad que define el significado de los valores X. 


_ La representación gráfica del conjunto R(X) será un rectángulo con la 
etiqueta R(X) en su interior, o a veces, si no nos interesa indicar explícitamente 
el nombre de la propiedad R, con sólo el nombre del atributo X en su interior: 
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R (X) Ó (Xx) 


A veces interesa considerar conjuntos de valores que son subconjuntos de 
otros. Esto lo indicaremos dando el mismo nombre al atributo de las relaciones 
unarias correspondientes. No es imprescindible hacerlo así para aplicar el 
proceso de diseño que vamos a describir a lo largo de este capítulo, pero ayuda 
a documentarlo y hacerlo más claro. Así, si partimos de R(X) y extraemos del 
conjunto R un subconjunto de simbolos X que cumplan un cierto predicado, $, 
tendremos una relación unaria que representaremos S(X). 


Ejemplo: 


Sea E(SS) el conjunto de los números de Seguridad Social de todos los empleados 
de una empresa. El predicado E significa «empleado». Los valores del atributo, 
SS, son símbolos formados por digitos que representan números de afiliados 
a la Seguridad Social. Consideremos ahora un subconjunto de E formado por 
todos los números de Seguridad Social de los empleados que están casados. Lo 
representaremos como C(SS) (predicado C: casados; atributo SS: números de 
Seguridad Social). 


Si consideramos el conjunto de todos los DNI (Documento Nacional de Identi- 
dad) de los empleados casados tendríamos una relación unaria diferente, en la 
que hay que dar al atributo un nombre distinto de SS, puesto que es un conjunto 
de símbolos que no está contenido en E(SS). En cambio, sería aconsejable 
mantener el mismo nombre del predicado, puesto que tiene el mismo significado 
(C: casados), aunque no es imprescindible. Asi, esta nueva relación podríamos 
llamarla C(DND. 


Consideremos ahora el conjunto de los números de Seguridad Social de los 
proveedores de la empresa. Aunque no es un subconjunto de E(SS), conviene dar 
al atributo el mismo nombre, SS, pues ambos conjuntos pueden considerarse 
subconjuntos de otro más amplio (el conjunto de los números de Seguridad Social 
de todos los ciudadanos del país). De forma que lo podríamos llamar PROV(SS) 
(PROV: proveedores; SS: número de Seguridad Social). 


Estos convenios de nombres son útiles para documentar y clarificar el 
proceso de diseño, como ya se ha dicho, pero no es imprescindible atenerse a 
ellos. 


Entre los elementos de estos conjuntos pueden existir asociaciones que 
expresan ciertas propiedades o predicados. El grado de una asociación es el 
número de conjuntos que intervienen en ella (asociaciones binarias, ternarias, 
etcétera). 


REPRESENTACION DE ASOCIACIONES BINARIAS 


Representaremos a una asociación binaria entre dos conjuntos de valores 
mediante una línea que una a los rectángulos participantes. En cada extremo de 
esta línea pondremos un símbolo, de acuerdo con una notación que veremos a 
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continuación, para indicar la «cardinalidad» de la asociación en ambos sentidos 
(o sea, el número de elementos asociados a uno dado). Si en alguno de los 
extremos es la cardinalidad mayor que 1 se dibujará en él una flecha. Además, 
a cada asociación se le da un nombre que suele ser el predicado o una 
abreviatura de él. Se escribirá este nombre al lado de la línea. Ejemplo: 


B (Y) 


Significado de los elementos de esta figura: 


e A(X): Conjunto de valores que cumplen la propiedad A. 
e B(Y): Conjunto de valores que cumplen la propiedad B. 


e R: Nombre del predicado que cumplen las parejas de valores X e Y 
asociados. 


e n: Cardinalidad. 


Para expresar la cardinalidad de la asociación emplearemos la notación 
siguiente: 


e n: Indica que a un elemento de un conjunto le pueden corresponder 0, 1, 


2, ..., n, elementos del otro (es una asociación múltiple que incluye el 
cero). 
e m: Indica que a un elemento le pueden corresponde 1, 2, ..., n (asociación 


múltiple excluyendo el cero). 
e 1: Indica que a cada elemento le corresponde otro. 


e c: Indica que a un elemento le pueden corresponder 0 ó 1 («c» viene de 
«condicional»). 


Cuando queremos representar la cardinalidad de una asociación, lo hacemos 
incluyendo entre paréntesis, y separados por dos puntos, dos de los símbolos 
anteriores. El de la izquierda representará la cardinalidad yendo de derecha a 
izquierda, y el otro en el sentido inverso. Así, por ejemplo, si decimos que la 
asociación entre A(X) y B(Y) es de cardinalidad (m: 1), estamos indicando que 
a todo elemento Y de B le corresponde un número de elementos X de A que 
puede ser 1, 2,..., o n, y que a cada elemento X de A le corresponde exactamente 
otro de B. La representación gráfica sería: 


Al(Xx) 


B (Y) 
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Con estos símbolos podremos tener diez tipos posibles de asociaciones 
binarias: (n:n), (n:m), (n:c), (n:1), (m:m), (m:c), (m: 1), (c:c), (c:1), (1: 1). 


Puesto que el conjunto de valores incluidos en la cardinalidad representada 
con n incluye a los representados con m y c, y éstos a su vez al valor representado 
con la cardinalidad 1, convendremos en que, de ahora en adelante, y salvo que 
se diga expresamente lo contrario, cuando enunciemos una propiedad para la 
cardinalidad n también se cumplirá para las cardinalidades m, c y 1, y las 
propiedades de m y c se cumplirán también para 1. Es decir, si la flecha se lee 
«implica»: 


(1) >> (6) 


(1): == (11) 


Evidentemente, una asociación binaria R entre dos conjuntos A(X) y B(Y), 
podremos reflejarla en el esquema relacional de diseño mediante una relación 
binaria en la que cada tupla está formada por las parejas de valores <X, 
Y > asociados. En esta relación binaria usaremos los mismos nombres de atribu- 
tos, X e Y, que en las relaciones participantes. 


Por tanto, el diagrama 


A (X) = B (Y) 


dará lugar al siguiente esquema relacional de diseño: 


e A(X) (conjunto de valores X que cumplen el predicado A). 
e B(Y) (conjunto de valores Y que cumplen el predicado B). 


e R(X, Y) (conjunto de parejas de valores de X e Y que cumplen el 
predicado R). 


Es posible que exista más de una asociación entre los mismos rectángulos: 


A (X) B (Y) 
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En este caso el esquema de diseño sería: 


A(X), B(Y), R(X, Y), S(X, Y) 
Ejemplo 1: 


Consideremos un centro de enseñanza que asigna un número de matrícula, MAT, 
a sus alumnos. Tendríamos los conjuntos de valores siguientes: 


P(DNI): Conjunto de los DNT's de los profesores del centro. 


A(MAT): Conjunto de los números de matrícula de los alumnos del centro. 
Podríamos considerar las dos asociaciones siguientes: 


T(DNI, MAT): Profesores que son tutores de alumnos. 


D(DNI, MAT): Profesores que dirigen tesis doctorales a alumnos. 


Los correspondientes diagrama y esquema de diseño serían: 


7 


A (MAT) 


n 


P(DND), A(MAT), T(DNI, MAT), D(DNI, MAT) 


También puede ocurrir que das parejas de valores que se asocian se tomen 
de un mismo conjunto, A(X). El diagrama sería en este caso: 


A (X) 


En el diagrama anterior hemos calificado al atributo X para distinguir los 
dos papeles que desempeña en R. El esquema de diseño sería: 


A(X), R(X.1, X.2) 


Ejemplo 2: 


Consideremos el conjunto de valores, DEP(N), de todos los números de departa- 
mento de una empresa. Entre ellos existe una asociación definida por la dependen- 
cia organizativa de unos respecto a otros. Así, la asociación ORG (N.1, N.2) 
indica qué departamentos (N.1) dependen de otros (N.2) en el organigrama de la 
empresa. Los correspondientes diagrama y esquema de diseño serían: 
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DEP (N) 


ORG (N.1, N.2) 


DEP(N), ORG(N.1, N.2) 


Ejemplo 3: 

Sea E(DNI) el conjunto de DNT's de los empleados de una empresa. Considere- 
mos el predicado «Jefe» que nos asocia a cada jefe con sus subordinados. Puede 
representarse esta asociación con la relación JEFE (DNIJ, DNI.S). El diagrama 
y el esquema de diseño serían análogos a los ya vistos anteriormente. 


REPRESENTACION DE ASOCIACIONES 
BINARIAS IMPLICITAS 


Consideremos dos conjuntos de valores en que los atributos son comparables, 
es decir, homogéneos. El criterio para considerar si son homogéneos o no 
puede ser tan amplio como se desee. Por ejemplo, podríamos considerar que son 
homogéneos si ambos son alfabéticos o si ambos son numéricos, o si son 
cantidades expresadas en la misma unidad (por ejemplo, pesetas), o si toman 
valores en el mismo dominio, es decir, si significan lo mismo (por ejemplo, ambos 
son números de DNI), etc. 


Una vez definido un criterio de homogeneidad o comparación, podemos 
definir una asociación entre ambos conjuntos que ligue los valores que son 
iguales. A toda asociación de este tipo la llamaremos «implícita», y la representa- 
remos mediante una línea sin nombre de predicado, entre los rectángulos 
asociados. La cardinalidad la representaremos con el mismo convenio ya descrito 
anteriormente. 


Normalmente sólo estaremos interesados en representar las asociaciones 
implícitas cuando los atributos tengan el mismo significado. Convendremos, de 
ahora en adelante, que en este caso daremos el mismo nombre a los atributos 
para hacer más evidente la existencia de la asociación implicita. 


Ejemplo 1: 


Supongamos que tenemos los conjuntos: 
E(DND: Conjunto de números de DNI de los empleados. 


C(NUM): Conjunto de números de DNI de los empleados casados. 
En este ejemplo suponemos que no estamos siguiendo el convenio de dar el mismo 


nombre a atributos con igual significado, pues DNI y NUM son ambos números 
de DNI. Existe entre ellos una asociación implícita que representaremos asi: t 
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E (DNI) C (NUM) 


E (DNI) 


Evidentemente, la cardinalidad de una asociación implícita no puede ser 
múltiple. Es decir, sólo puede ser c, 1 ó 0. Una cardinalidad 0 significa que no 
hay valores comunes a ambos conjuntos (su intersección es vacía) y, por tanto, 
podemos omitir la línea entre los rectángulos (o poner como cardinalidad (0: 0) 
si queremos indicar esta condición explícitamente). 


El objetivo de representar las asociaciones implícitas es poder indicar su 
cardinalidad en el dibujo. 

Ejemplo 2: 

Supongamos que tenemos los conjuntos siguientes en un centro de enseñanza: 
P(DND: Conjunto de DNT's de los Profesores. 
A(DNI): Conjunto de DNTP's de los Alumnos. 

Si suponemos que ningún alumno puede ser profesor, no habrá valores comunes 

entre los conjuntos P y A (cardinalidad cero). 

En caso contrario, sí los habrá. En nuestro ejemplo podríamos tener: 


Esta cardinalidad indica que algunos profesores pueden ser alumnos, y viceversa. 


Naturalmente, entre dos conjuntos con el mismo atributo, puede haber, 
además de la asociación implicita, otras explícitas. 


Ejemplo 3: 
Volvamos a nuestro ejemplo anterior del centro de enseñanza. Podríamos tener 
el diagrama: 


P (DNI) 
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donde: 


T: Profesores tutores de alumnos. 
D: Profesores que dirigen tesis doctorales de alumnos. 


El esquema de diseño relacional sería: 


P(DND, A(DND, T(DNI.P, DNLA), D(DNI.P, DNILA) 


CARDINALIDAD Y CONDICIONES DE INTEGRIDAD 


Como ya hemos visto, cuando tenemos una asociación binaria explicita, tal 
como: 


el esquema de diseño está formado por tres relaciones: 
A(X), B(Y), R(X, Y) 


Observemos, sin embargo, que en este esquema no se ha reflejado para nada 
la cardinalidad de R, dato que sí consta en el diagrama anterior. Para reflejar 
esto hay que introducir condiciones de integridad en el esquema. Veamos cómo: 


1) Si la asociación R tiene en un extremo, por ejemplo, en el B(Y), la 
cardinalidad n (o c) significa que algunos valores de X en A pueden no 
estar en R. O sea, que R(X]<A(X). 

Ejemplo de valores: 
AGD) BO) ¿ROCY 
1 (a, 1) 


a 
b 2 (a, 2) 
c 3 (e; 3) 
d 4 (c, 4) 
e 5 (e, 5) 
2) Si la asociación R tiene en un extremo, por ejemplo en el B(Y), la 


cardinalidad m (ó 1) significa que todos los valores de X en R son los 
mismos que los de X en A. De otro modo: si R(X, Y) es (n:m) o (n:1), 
se verifica que R[X]=A(X). 


Por tanto, la relación A(X) es redundante con la R(X, Y) y se puede 
en principio suprimir del esquema de diseño, quedando éste con dos 
relaciones: B(Y), R(X, Y). 
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Ejemplo de valores: 


AQ B(O)  R(X Y) 


ode» 


E 


Y 


Si la asociación R tiene en un extremo, por ejemplo en el B(Y), la 

cardinalidad c (Ó 1) significa que existe una DF (X>Y) en R. En efecto, 

como a cada valor de X en R sólo le corresponde un Y, los valores de X 

Al e repetirse en R, es decir, X es la clave de R, y por tanto además 
a 


Ejemplo de valores: 
AD BY". RIA Y) 


a — 1 (a, 1) 

O (b, 1) 

c E (c, 3) 
d 4 
5 


Aplicando estas ideas tendremos los siguientes esquemas de diseño para los 
diez tipos posibles de cardinalidad: 


1) Cardinalidad de R: (n:n). 
Esquema de diseño: A(X), B(Y), R(X, Y). 
Cond. de integridad: R[X]<A(X); R(Y) <B(Y). 
2) Cardinalidad de R: (n:m). Ae 
Esquema de diseño: B(Y), R(X, Y). 
Cond. de integridad: R[Y]<B(Y). - o 
3) Cardinalidad de R: (n:c). ' 
Esquema de diseño: A(X), B(Y), R(X, Y). 7 
Cond. de integridad: R[X]<A(X); R[Y]<B(Y); Clave de R: X. 
4) Cardinalidad de R: (n: 1). 
Esquema de diseño: B(Y), R(X, Y). 
Cond. de integridad: R[Y]<B(Y); Clave de R: X. 
5) Cardinalidad de R: (m:m). 
Esquema de diseño: R(X, Y). 
Cond. de integridad: Ninguna. 
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6) Cardinalidad de R: (m:c). 

Esquema de diseño: A(X), R(X, Y). 

Cond. de integridad: R[X]< A(X); Clave de R: X. 
7) Cardinalidad de R: (m: 1). 

Esquema de diseño: R(X, Y). 

Cond. de integridad: Clave de R: X. 
8) Cardinalidad de R: (c:c). 

Esquema de diseño: A(X), B(Y), R(X, Y). 

Cond. de integridad: R[X]<A(X); R[Y]<B(Y); Claves de R: X e Y. 
9) Cardinalidad de R: (c: 1). 

Esquema de diseño: B(Y), R(X, Y). 

Cond. de integridad: R[Y]<B(Y); Claves de R: X e Y. 
10) Cardinalidad de R: (1: 1). 

Esquema de diseño: R(X, Y). 

Cond. de integridad: Claves de R: X e Y. 


Todo esto es también aplicable a las asociaciones implicitas. Tendríamos los 


casos siguientes: 
A(X) > > B (X) 


1) Cardinalidad: (c:c). 
Esquema de diseño: A(X), B(X). 
Cond. de integridad: Ninguna. 
2) Cardinalidad: (c: 1). 
Esquema de diseño: A(X), B(X). 
Cond. de integridad: A(X)<B(X). 
3) Cardinalidad: (1: 1). 
Esquema de diseño: A(X). 
Cond. de integridad: A(X)=B(X). 
4) Cardinalidad: (0: 0). 
Esquema de diseño: A(X), B(X). 
Cond. de integridad: No puede haber valores comunes entre A(X) y B(X). 
Con las reglas expuestas podemos obtener el esquema relacional de diseño 


correspondiente a una asociación binaria incluyendo las condiciones de integri- 
dad deducibles de la cardinalidad. Esto no significa que no pueda haber otras 
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3) 


condiciones de integridad, no expresables mediante la cardinalidad de la aso- 
ciación. : 


Ejemplo 


Reconsideremos la asociación JEFE entre los empleados de una empresa. El 
diagrama es: 


E (DNI) 


El esquema relacional de diseño será: 
Relaciones: E (DND), JEFE (DNI.J, DNL.S). 
Condiciones de integridad: Clave de JEFE: (DNL.S). 


No obstante, hay que cumplir una condición adicional, no expresada por la 
cardinalidad (n:c), que es que sólo un empleado no tiene jefe (el jefe supremo o 
jefe de todos los jefes). Sean, por ejemplo, los valores siguientes: 


E (DND JEFE (DNI.J, DNLS) 


ZO uu 4 un 
Ca 
N 
un 
= 


Sólo el empleado 1 no figura como subordinado en la relación JEFE. 


Como hemos visto, las asociaciones binarias en que la cardinalidad en un 


extremo no supera a 1 dan lugar a una Dependencia Funcional y, consiguiente- 
mente, a una clave. Por ello las llamaremos «asociaciones funcionales». Clasifica- 


remos entonces a las asociaciones binarias, según su cardinalidad, en tres tipos: 
1) Asociaciones plurales: (n:n), (n:m), (m:m). 
2) Asociaciones funcionales: 
a) Asociaciones funcionales completas: (n:1), (m:1), (c: 1).(1:1). 


b) Asociaciones funcionales incompletas: (n:c), (m:c), (c:c). 
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DIAGRAMA DE CONJUNTOS Y ASOCIACIONES 


Con los elementos analizados hasta aquí podemos representar gráficamente 
conjuntos de valores y asociaciones binarias entre ellos. Al diagrama así formado 
lo llamaremos diagrama C/A (diagrama de Conjuntos y Asociaciones). Un 
diagrama C/A está formado por tanto por los elementos siguientes: 

1) Rectángulos, que representan relaciones unarias o conjuntos de valores. 


2) Líneas con nombre. Cada una une dos rectángulos (no necesariamente 
distintos) y representa una asociación binaria explícita entre los elementos 
de éstos. En los extremos de las lineas se representa la cardinalidad. 


3) Líneas anónimas. Sirven para representar en el diagrama la cardinalidad 
de las asociaciones implícitas deducibles de los atributos comunes entre 
los conjuntos. 


A partir de un diagrama C/A se puede obtener el esquema relacional de 
diseño de la siguiente forma: 

1) Cada rectángulo da lugar a una relación unaria. 

2) Cada línea con nombre da lugar a una relación binaria. 


3) Las cardinalidades de las líneas dan lugar a condiciones de integridad 
(claves e integridad de referencia). 


La representación de los datos mediante el diagrama C/A, tal como la hemos 
descrito hasta aquí, presenta algunos inconvenientes y limitaciones: 
1) Es demasiado prolija. Conviene dotarla de mayor concisión. 


2) No permite representar asociaciones binarias en las que participen elemen- 
tos de otras asociaciones. 


3) No permite representar asociaciones de grado superior a 2. 


Vamos a introducir algunas modificaciones para resolver estos inconvenien- 
tes. Para ello tomaremos como elementos básicos de construcción los rectángu- 
los, para representar relaciones n-arias, y las asociaciones funcionales completas. 
Estas nos van a permitir definir las entidades y representar asociaciones de orden 
superior. 


Estas modificaciones serán el resultado de aplicar unas reglas de transforma- 
ción, que son las siguientes: 

1) Propagación de claves. 

2) Definición de claves. 

3) Agregación de rectángulos. 

4) Supresión de rectángulos. 
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REGLA DE PROPAGACION DE CLAVES 


Hasta ahora hemos usado los rectángulos en los diagramas para representar 
conjuntos de valores simples, es decir, relaciones unarias. A partir de ahora 
vamos a utilizarlos para representar, en general, conjuntos de valores simples o 
compuestos, es decir, relaciones de grado cualquiera. Así, por ejemplo, la 
relación R(X, Y, Z) la podemos representar así: 


R(X, Y, Z) 


Este rectángulo representa el conjunto de tuplas de la relación R. Suponga- 
mos entonces que entre dos rectángulos, A(X) y B(Y), existe una asociación 
funcional completa explícita, R(X, Y): 


(Diagrama (1) 


En el diagrama anterior podría haber, en general, otras asociaciones binarias 
entre A y B, además de R. Estas asociaciones podrían ser de A y B con otros o 
incluso entre sí. Esto se indica en la figura anterior con puntos. El esquema 
relacional de diseño será: 

R(Y), REX-, Y); Condiciones: R[Y]<B(Y). (Nota: en la relación R. X es 
la clave. Esto lo representamos poniendo la X entre guiones: R(-X-, Y). 


Por lo dicho anteriormente, el rectángulo: 


R (X=, Y) 


representa el conjunto de tuplas de la relación R(X, Y), indicando además cuál 
es su clave primaria. 


Entonces podemos substituir el rectángulo A(X) del diagrama (1) anterior 
por el rectángulo R, quedando este diagrama transformado así: 
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Además de reemplazar el rectángulo A por el R, hemos transformado la línea 
R que unía a A con B en una línea anónima, y hemos mantenido todas las demás 
líneas que confluían en A tal como estaban. Es importante subrayar que hemos 
transformado una ASOCIACION EXPIICITA R en una asociación IMPUCI- 
TA, es decir, que si aplicamos esta transformación a todas las asociaciones 
explícitas del diagrama, al final sólo habrá en éste asociaciones binarias, funcio- 
nales completas e implícitas. 


Todas las líneas que confluyen en el diagrama anterior en R representan 
asociaciones (explícitas o implícitas) entre las tuplas de R y las de otros 
rectángulos (o las suyas propias) o, lo que es igual, entre los valores de la clave 
de R y otras claves. 


Sean, en general, dos rectángulos, A(X, X1, ...) y B(Y, Yl, ...), y una 
asociación funcional completa R entre sus tuplas o, lo que es lo mismo, entre 
sus claves: 


El esquema relacional de diseño será: 
Relaciones: A(-X-, X1, ...), BEY-, Yl, ...), REX-, Y). 
Condiciones: R[X]=A[X], R[Y]<BT[Y]. 


En definitiva, llamaremos «propagar» la clave Y del rectángulo B, al rectán- 
gulo A, a la transformación siguiente: 


1) El rectángulo A lo reemplazamos por R(-X-, Y, X1, X2, ...), donde esta 
relación es el resultado de (A(-X-, X1, ...)*R(X-, Y). 


2) Todas las líneas que confluyen en A confluyen ahora en el rectángulo R 
que lo substituye. 


3) La asociación R explícita que unía a los rectángulos A y B, se transforma 
en implícita. 


El diagrama quedaría transformado en el siguiente: 


R (-X,Y,X1...) 
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En este dibujo la línea anónima entre los rectángulos R y B indica que, si 
asociamos cada tupla de R con todas las de B en que el atributo común, Y, tiene 
igual valor, cada tupla de R resultará asociada a una, y sólo una, de B, y cada 
tupla de B resultará asociada a ninguna, una o varias, de R. 


El esquema relacional de diseño será: 


Relaciones: B(-Y-, Y 1, ...), R(X-, Y, X1, ...). 
Condiciones: Integridad de referencia: Todo valor de Y en R debe existir en B. 
q 


ASOCIACIONES IMPLICITAS ENTRE RELACIONES UNARIAS 


Ya hemos visto que entre dos relaciones que tengan atributos comunes existe 
una asociación binaria implícita. Vamos a recapitular lo dicho sobre este tipo 
de asociaciones y a considerar algunas propiedades adicionales. 


Sean dos relaciones unarias, A(X) y B(X), con el mismo atributo, X. La 
asociación implícita entre ellas es la que se obtiene emparejando los valores de 
X que son iguales en A y en B. 


Puesto que la existencia de este tipo de asociaciones es directamente deducible 
a partir de la existencia de un atributo común, es en principio redundante 
representarlas en el diagrama. Sin embargo, es útil hacerlo para poder indicar 
sobre ellas la cardinalidad de la asociación. Para representar una asociación de 
este tipo dibujamos una línea «anónima». 


| 
A (X) B (X) 


Evidentemente la cardinalidad no puede superar a 1. Por tanto, los casos 
posibles de cardinalidad son: 

(0:0): A(X) y B(X) son conjuntos disjuntos. 

(1: 1): Ambos conjuntos son iguales, A(X)=B(X). 


(c: 1): Todos los valores de A(X) están en B(X), pero no al revés necesaria- 
mente. Es decir, A(X)<B(X). 


(c:c): Puede haber valores comunes, o no, entre A y B. 


Ejemplo: 
El diagrama: 
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dará lugar al esquema de diseño: 


Relaciones: A(X), B(X). 
Condiciones: Todos los valores de X en A deben estar en B. 


| ASOCIACIONES IMPLICITAS ENTRE RELACIONES N-ARIAS 


Sean ahora dos relaciones n-arias, A(X, Y, Z) y B(X, Y, W), donde X, Y, Z 
y W son atributos posiblemente compuestos. Por el hecho de tener atributos 
comunes existen asociaciones implícitas entre ambas, que se obtienen emparejan- 
do las tuplas de A y B que tienen iguales valores en todos, o en parte, de los 
atributos comunes. Si en todos, diremos que se trata de una asociación implícita 
total, y si no, parcial. Normalmente, mientras no se diga lo contrario, al hablar 
de una asociación implícita supondremos que es total. 


Las asociaciones implícitas las representaremos por una línea anónima sobre 
cuyos extremos se indicarán las cardinalidades respectivas, así como los atributos 
que intervienen en ella. Estos últimos pueden omitirse si la asociación implícita 
es total y no hay ambigiedad para designarlos. La cardinalidad puede venir 
dada, en general, por una pareja formada por cualquiera de las diez combinacio- 
nes posibles entre los valores n, m, c y 1, o la pareja (0:0) si no hay valores 
comunes. 


Consideremos el siguiente diagrama: 


A(X.1,X.2,Y) 


(x.1,Y) PEZ ncd) 


Este diagrama representa que la asociación implícita que empareja las tuplas 
de A y B cuando coinciden los valores de (X.1, Y) en A con los de (X.2, Y.1) 
en B, tiene una cardinalidad (m: 1). 


Ejemplo 1: 


Sean dos relaciones A(X, Y, Z) y B(X, Y, W). Los siguientes valores corresponde- 
rían a una asociación de tipo (n:c) según los valores de (X, Y), de tipo (n:m) 
según los valores de (X) y de tipo (n: 1) según los valores de (Y): 
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El diagrama correspondiente sería: 


A (X,Y,Z) 


Normalmente sólo estaremos interesados en representar la asociación implíci- 
ta total. 


Obsérvese que una asociación implícita empareja las mismas tuplas de A y B 
que se emparejan también al ayuntar ambas relaciones por sus atributos comu- 
nes. Por ello la cardinalidad de la asociación nos da una primera aproximación 
del coste de la yunción. Si, por ejemplo, la asociación implícita entre A(X, Y) y 
B(X, Z) es (n: 1), el número de tuplas de (A + B) es igual al de A. Si fuera (n:c), 
el número de tuplas de (A * B) no puede superar al de A. Si fuera (n:n), y la 
cardinalidad media fuera, por ejemplo, (3:2) (o sea, a cada tupla de A corres- 
ponden, en promedio, dos de B, y a cada una de B, 3 de A), cada valor de X 
común a A y B estará repetido, en promedio, en 6 tuplas de (A x B). 


Los valores de la cardinalidad de la asociación implícita total están condicio- 
nados por los de las asociaciones implícitas parciales. Veamos esto. 


Sea el diagrama: 


(Xx) 


A (X,Y,Z) B (X,Y,W) 


Tenemos, pues, que la cardinalidad según (X) es (al:b1), y según (Y) es 
(a2:b2). Vamos a ver qué valores puede tener la cardinalidad según (X, Y). 


A una tupla de A le corresponden, en B, bl tuplas con igual valor en X, y 
b2 tuplas con igual valor en Y, pero es posible que no coincidan en ninguna de 
estas tuplas X e Y a la vez, o es posible que sí. El número de tuplas en las que 
sí pueden coincidir viene dado, en función de b1 y b2, por la tabla siguiente: 
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Por tanto, los valores posibles para la cardinalidad de la asociación implícita 
total en el extremo correspondiente a B vendrá dada por la tabla siguiente: 


b2: 0 


of es [e 
o] 


m , 
: 
Ejemplo 2: 


Veamos un caso en que la asociación parcial según X es (m: 1), según Y es (m:c) 
y según (X, Y) es (n:c): 


Otro caso interesante que se presenta en los diagramas es el de asociaciones 
implícitas compuestas a partir de otras, cuya cardinalidad también está condicio- 
nada por éstas. Precisemos esto. Sea el diagrama: 


En este diagrama la cardinalidad de la asociación implícita entre A y B es 
(al:b1), y entre B y C es (a2:b2). Obviamente, puesto que X es un atributo 
común a A y B, y a B y C, también lo es a A y C, por lo que podemos dibujar 
una asociación implícita entre éstos, y diremos que esta asociación es el resultado 
de componer las asociaciones A-B y B-C. Sea (c1:c2) la cardinalidad de la 
asociación compuesta: 
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Si bl es 1 ó m, es decir, si todos los valores de X en Á existen en B, los 
valores posibles de cl vienen dados por la tabla siguiente: 


Si bl es có n, es decir, si algunos valores de X en A no existen en B, los 
valores posibles de cl vienen dados por la tabla siguiente: 


1d m..c, 1 


PTA DA DOE 


lóm 
, , , 1 


0 
, 
, 
, 


dl 
REGLA DE DEFINICION DE CLAVES 

Otra propiedad interesante de las asociaciones implícitas es que la cardinali- 
dad (m:c), Ó (m:1), ó (1:c), ó (1 : 1) define la existencia de una superclave. 


Sean dos relaciones n-arias, A(X, Y, Z) y B(X, Y, W), con atributos comunes 
X e Y (posiblemente compuestos). Si la asociación implícita según X entre A y 
B es (m:c), X es una superclave en B. 


En efecto, si no lo fuera, podría tener X valores repetidos en B, y habría por 
consiguiente más de una tupla de B asociada a una de A, lo que contradice a 
la cardinalidad c. 
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Si no hay ningún subconjunto de X tal que la asociación implícita correspon- 
diente tenga cardinalidad (m:c), entonces X es una superclave mínima, es decir, 
es una clave. 


Ejemplo: 


Si tenemos (X no compuesto): 


El recíproco no es cierto. Sin embargo, sí puede afirmarse que si X es una 
superclave de A, e interviene en una asociación implícita, la cardinalidad de ésta 
no puede ser múltiple (es decir, m o n). Así, si tenemos A(-X-, Y) y B(X, Z), la 
asociación implícita entre A y B ha de tener cardinalidad c ó 1 en el extremo A. 


REGLA DE AGREGACION DE RECTANGULOS 


En el caso de una asociación funcional completa biunívoca, explícita o 
implícita, podemos fundir los dos rectángulos en uno. A esta transformación del 
diagrama la llamaremos «agregar» dos rectángulos. 


Comprobemos la justificación de esta regla. Consideremos primero una 
asociación explícita: 


El esquema relacional de diseño será: 


Relaciones: A(-X-, X1), B(-Y-, Y1), REX-, -Y-). 
Condiciones: A[X]=R[X]; B[Y]=R[Y]. 


Este diseño es equivalente a: 


Relaciones: S(-X-, -Y-, X1, Y1), donde S=A*R*B. 
Condiciones: ([). 
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Por tanto, el diagrama puede transformarse substituyendo A y B por S: 


S (-X-,-Y-,X1,Y1) 


Consideremos ahora una asociación implícita: 


Ambos rectángulos se pueden subtituir por C=AxB: 


C (-X-,Y,Z) 


Al agregar dos rectángulos, todas las lineas (asociaciones) que confluyen en 
los agregandos, confluirán en el rectángulo resultante y se conservarán en éste las 
claves originales. 

Ejemplo 1: 


Sea un diagrama con una asociación implícita (1: 1) y otra explícita (1:n): 


S (-X-,Y,Z) 


R (LA, X.B) 


(donde S=A + B). 


También puede ocurrir que la asociación implícita usada para la agregación 
sea una asociación parcial. 
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Ejemplo 2: 


Si agregamos los rectángulos por la línea de la asociación implicita según (X) el 
diagrama se transforma en: 


(donde R=AYB (X.A=X.B)). 


Si ahora agregamos los rectángulos por la línea de la asociación implícita según 
(Y) el diagrama se transforma en: 


y S (Y-, -X.A-, Z, y 

Cc Cc 
(E We 
X.A) X.B) 


(donde S=AYB(Y.A =Y.B)). 


Podría pensarse en intentar la agregación en el caso de una cardinalidad 
cualquiera, en vez de restringirla a la cardinalidad (1:1). Si tenemos, por 
ejemplo, dos rectángulos A(X, Y) y B(X, Z), podríamos intentar substituirlos 
por el R(X, Y, Z), siendo R=A *B. Para que esto fuera válido, todos los valores 
de X en A o en B deberían aparecer en R. Esto excluye las cardinalidades n y c. Es 
decir, que la asociación implícita entre A y B debe ser (m:m) o (m:1). Pero 
esto nos llevaría a relaciones no normalizadas. En efecto, como R, debe ser es 
descomponible reversiblemente en A y B, se verifica en R que X>Y|Z, y 
como X no es clave en R, pues si lo fuera tendría que ser (1: 1) la cardinalidad 
de la asociación entre A y B, se deduce que R no está normalizada. Por tanto, 
no haremos este tipo de transformaciones. 
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En resumen, la regla de agregación de rectángulos se aplicará a asociaciones 
de cardinalidad (1: 1), explícitas o implícitas. 


REGLA DE SUPRESION DE RECTANGULOS 


Si un rectángulo participa con todos sus atributos en una o más asociaciones 
implícitas, de las que una al menos es de cardinalidad (1: m), puede suprimirse 
del diagrama. 


Justifiquemos esto con algunos ejemplos: 


Ejemplo 1: 
Sea el diagrama (X es posiblemente compuesto): 


... A (X.Y) B (X) 
m 1 


El esquema de diseño relacional es: 


Relaciones: A(X, Y), B(X). 
Condiciones: A[X]=B[X]. 


Es decir, que B(X) es redundante, por lo que puede suprimirse. Esto se refleja en 
el diagrama transformándolo en el siguiente: 


o A (X,Y) 


Veamos el caso en que el rectángulo que se suprime participa en más de una 
asociación. Sea el diagrama: 


Ejemplo 2: 
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En este diagrama, como siempre, X, Y y Z pueden ser atributos compuestos. El 
rectángulo C participa en dos asociaciones, con A y con B, en ambas con todos 
sus atributos, y una de ellas es de cardinalidad (1:m). Por tanto, según la regla 
anterior, es suprimible. En efecto, el esquema de diseño es: 


Relaciones: A(X, Y), B(X, Z), C(X). 
Condiciones: A[X]=C(X); B[X]<C(X). 


Por tanto, C(X) es redundante con A(X, Y), por lo que puede suprimirse. Sin 
embargo, al suprimir C también suprimimos sus asociaciones, con lo que perde- 
mos la información sobre la cardinalidad de la asociación entre C y B. Para no 
perder esta información hay que dibujar la línea que representa a la asociación 
compuesta por A-C y C-B, es decir, la asociación implícita entre A y B pasando 
por C a través del atributo común X: 


¿Cuál es la cardinalidad de esta asociación entre A y B? Viene definida por la 
tabla de cardinalidades de asociaciones compuestas que ya se ha mostrado an- 
teriormente. Según esta tabla, el valor de a puede ser m ó 1, y el de b puede 
ser cualquiera (n, m, c, 1, 0). Si no hay condiciones adicionales que nos permitan 
restringir estos valores, con la sola información del diagrama no podemos hacerlo, 
por lo que tomaremos los más generales, es decir, a=m y b=n. Por tanto, el 
diagrama queda así: 


Suprimamos C: 
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Ejemplo 3: 
Supongamos que hay dos rectángulos como el C anterior, en vez de uno: 


A (X,Y,Z) B (X,Y,W) 


Representemos las asociaciones implícitas compuestas entre A y B según X 
(camino A-C1-B) y según Y (camino A-C2-B). Sus cardinalidades vienen dadas 
por la tabla de composición de cardinalidades. Tomando los valores más genera- 


les, el diagrama queda: 
a 


A (X,Y,Z) (Y) B (X,Y,W) 
Como ya sabemos, Cl y C2 son redundantes, por lo que el diagrama se 
transforma en: 


n (X) m 


m n 


De acuerdo con lo explicado anteriormente sobre cardinalidad de asociaciones 
implícitas parciales, la cardinalidad de la asociación implícita total entre A y B 
puede ser n, c ó 0. Tomando los valores más generales, (n : n), queda el diagrama: 
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A (X,Y,Z) 


Este último diagrama, sin embargo, no es equivalente al anterior en el que 
figuraban las cardinalidades de las asociaciones parciales, por lo que puede ser 
interesante conservar éste. En efecto, las asociaciones parciales nos permiten 
expresar que: A[X]<B[X]; B[Y]<A[Y]. Estas condiciones han desaparecido en 
el último diagrama. 


En resumen, al suprimir un rectángulo hay que dibujar todas las asociaciones 
que desaparecen, calculando su cardinalidad mediante la tabla de composición 
de cardinalidades. 


La regla de Supresión enunciada anteriormente podría generalizarse. En 
efecto, hemos establecido como condición para poder suprimir un rectángulo que 
todos sus atributos participen en las asociaciones en las que interviene. Esto no 
es necesario. Basta que participe en una asociación (1 : m) con todos sus atributos 
para que ya se pueda suprimir, aunque participe en otras con solamente parte 
de sus atributos. Estas otras asociaciones habria que reflejarlas en el diagrama 
resultante, lo que puede ser complicado. Como además en la práctica suele bastar 
con la regla que hemos enunciado al principio, nos limitaremos a ella. 


EJEMPLOS DE DIAGRAMAS DE CONJUNTOS 
Y ASOCIACIONES 


Tomemos un diagrama C/A formado por múltiples rectángulos y líneas. 
Recordemos lo que estos elementos representan: 


1) Los rectángulos representan conjuntos de valores, o sea, relaciones unarias. 


2) Las líneas representan asociaciones explícitas o implícitas. 


Apliquemos ahora a este diagrama las transformaciones siguientes: 


1) En todas las líneas que representen asociaciones funcionales completas 
explícitas y no biunivocas (o sea, (n:1), (m:1) o (c:1)) efectuamos la 
Propagación de Clave. Con ello, todas estas asociaciones pasan a ser 
implícitas. 


2) En todas las líneas que representen asociaciones biunivocas (o sea, (1: 1) 
efectuamos la Agregación de los rectángulos. 


3) Efectuamos todas las Supresiones de rectángulos posibles. 


El resultado de estas transformaciones será otro diagrama, formado también 
por rectángulos y líneas que representan lo siguiente: 


1) Los rectángulos representan ahora relaciones n-arias. 


2) Las líneas representan asociaciones binarias, como antes, pero con la 
diferencia de que ahora no hay en el diagrama ninguna asociación 
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explícita que sea funcional completa. O sea, todas las asociaciones explíci- 
tas que quedan son (n:n), (n:m), (n:c), (m:m), (m:c) o (c:c). 


Veamos algunos ejemplos de transformación de diagramas. 


Ejemplo 1: 
Sea el diagrama C/A: 


Suprimiendo rectángulos queda: 


E (-X-,X1,X2,X3) 


Ejemplo 2: 
Sea el diagrama C/A: 
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Propagando las claves queda: 


B2 (Y2) 


Suprimiendo rectángulos queda finalmente: 


C (-X-,X1,X2) 


B (-Y-,X,Y1,Y2) 


Ejemplo 3: 
Sea el diagrama C/A: 


1 


R1 
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Propagando las claves queda: 


n 


E (-Y-,Y1,Y2) F (=2-,X,X3) 


n e 


Este diagrama, como vemos, tiene 4 rectángulos (D, E, F y A3), dos asociaciones 
explícitas, una, T, que es (n:n), y otra, R6, que es (n:c), y tres asociaciones 
implícitas, de las que dos son totales y la otra parcial. 


El esquema de diseño será: 
Relaciones: A3(X3), D(X=, X1, X2, X3), ECY-, Y1, Y2), F(EZ-, X, X3), 
T(X, Y), R6EY-, Z). 
Condiciones: D[X3]< A3(X3); F[X3]<A3(X3); F[X]<D[X]. 
(Obsérvese que todo valor de X en F, además de existir en D, tiene que estar en 


D no repetido, pero esto ya se cumple por ser X clave en D, por lo que sería 
redundante incluir esta condición.) 
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REPRESENTACION DE ASOCIACIONES 
ENTRE ASOCIACIONES 


Los elementos de una asociación binaria pueden participar a su vez en otra 
asociación binaria. 


Ejemplo 1: 


Cada pareja de valores asociados en la asociación A (PRODUCTOS, ZONAS), 
que expresa qué productos se venden en cada zona, se asocia a su vez con un 
elemento del conjunto PR (PRECIO) (o sea, cada producto en cada zona, se 
vende a un determinado precio). 


La utilización de rectángulos para representar relaciones n-arias, es decir, 
conjuntos de valores no atómicos, nos permite representar estas asociaciones 
entre asociaciones. 


Para ello vamos a representar con un rectángulo a toda asociación binaria 
explícita. 
Ejemplo 2: 


Sea una asociación R de este tipo entre los elementos de otras dos, A y B, como 
se indica en el diagrama C/A siguiente: 


Si representamos con el rectángulo: 


R (X.Y) 


al conjunto de parejas de valores (X, Y) (o sea, las claves de A y B), asociados 
en R, el diagrama anterior se transforma en: 


Vemos que la asociación explícita R, de cardinalidad (n:n), se ha transfor- 
mado así en un rectángulo y en dos asociaciones implícitas funcionales completas 
(o sea, de tipo (1: n)). 


Este último diagrama nos permite ya representar otras asociaciones en las 
que participen las tuplas de R. 
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Ejemplo 3: 


Sí hay una asociación explícita entre los elementos de R y las de otro rectángulo 
C(Z), tendríamos el diagrama siguiente: 


Obsérvese que si alguna de las dos asociaciones implícitas, de A con R o de 
B con R, es de cardinalidad (1 :c), el atributo común debe ser clave en R. 


Ejemplo 4: 
Así, si R es (n:c): 


DIAGRAMAS RE/R 


Supongamos que en un diagrama C/A transformamos en asociaciones bina- 
rias funcionales completas todas las asociaciones explícitas que no lo sean, 
mediante el procedimiento descrito de representarlas con un rectángulo. En este 
diagrama todas las asociaciones serán implicitas. A un diagrama con esta 
característica lo llamaremos «relacional». 


Si le aplicamos las Reglas de Definición y Propagación de Claves, y Agrega- 
ción y Supresión de Rectángulos, tantas veces como sea posible, obtendremos 
finalmente un diagrama al que llamaremos diagrama RE/R (diagrama Relacional 
de Entidades y otras Relaciones). 


_ A partir de un diagrama RE/R el esquema relacional de diseño se obtiene 
directamente, pues cada rectángulo da lugar a una relación del esquema, con sus 
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claves. Además, las asociaciones implícitas nos darán otras condiciones de 
integridad entre las relaciones (integridad de referencia, por ejemplo). 


Ejercitemos estas ideas con algunos ejemplos. 


Ejemplo 1: 
Sea el diagrama C/A siguiente (donde X, X1, Y, Y1, etc., son atributos simples): 


B2 (Y2) 


D (-X-,X1,X2) E(=Y-,Y1,Y2) 


Transformemos todas las asociaciones explícitas en implícitas: 


D (-X-,X1,X2) 


c1 (z1) 
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Supongamos que entre los elementos de R y los de C1 y C2 hay dos asociaciones, 
Tl y T2. Representémoslas en el diagrama: 


D (-X-,X1,X2) E (-Y-,Y1,Y2) 


C1 (Z1) 


Propagando claves y suprimiendo rectángulos llegamos finalmente al diagrama 
RE/R: 


E (-Y-,Y1,Y2) 


D (-X-,X1,X2) 


S (-X,Y-,21,22) 


El correspondiente esquema relacional de diseño será: 
Relaciones: D(-X-—, X1, X2), EEY-, Y1, Y2), SEX, Y-, Z1, Z2). 
Otras condiciones: S[X]<D[X]; S[Y]<E[Y]. 


Ejemplo 2: 
Supongamos ahora el mismo ejemplo anterior, pero con R de cardinalidad (n: 1). 


Diagrama C/A de partida: 
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Transformemos todas las asociaciones explícitas en implicitas: 


E (Y-,Y1,Y2) 


EN 


Si entre los elementos de R y los de C1 y C2 hay, como antes, asociaciones (m: 1): 


D (-X-,X1,X2) 


Propagando claves y suprimiendo rectángulos: 


D (-X-,X1,X2) E (-Y-,Y1,Y2) 


S(=X2,Y,21,22) 


Agregando rectángulos queda finalmente el diagrama RE/R: 


F (-X-,Y,X1,X2,21,22) E(-Y=11,Y2) 
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El correspondiente esquema de diseño será: 
F(X->, Y, X1, X2, Z1, Z2); EY-, Y1, Y2); F[Y]<E[Y]. 
Ejemplo 3: 
Supongamos otra vez el mismo ejemplo anterior, pero con R de cardinalidad 


(n:c). 
El diagrama C/A de partida se transforma en: 


DENIA E (-Y-.Y1,Y2) 


C1 (21) C2 (22) 


Lo completamos: 


D (-X-,X1,X2) 


C1 (21) 


Por Definición de Claves, y propagando claves y suprimiendo rectángulos llega- 
mos finalmente al diagrama RE/R: 


D (-X-,X1,X2) E (-Y-,Y1,Y2) 


S (-X-.Y,Z1,Z2) 
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El correspondiente diagrama relacional de diseño será: 
Relaciones: D(-X-, X1, X2); E EY, Y1, Y2); SEX-, Y, Z1, Z2). 
Otras condiciones: S[X]<D[X]; S[Y]<E[Y]. 

Ejemplo 4: 


Tomemos de nuevo el mismo ejemplo, pero ahora con R de cardinalidad (n:m), 
Til de cardinalidad (1: 1) y T2 (m:1): 


D (-X-,X1,X2) EL 112) 


Propagando claves y suprimiendo rectángulos llegamos finalmente al diagrama 
RE/R: 


D (-X-,X1,X2) 


E (-Y-,Y1,Y2) 


S (-X,Y-,-Z1-,Z2) 


El correspondiente diagrama relacional de diseño será: 


Relaciones: D(-X—, X1, X2); EY-, Y1, Y2); SEX, Y-, -Z-, Z1, Z2). 
Otras condiciones: S[X]=D[X]; S[Y]<E[Y]. 


Ejemplo 5: 


Sean PROD(NP) el conjunto de números de producto, ZONA(NZ) el conjunto 
de números de zona y VEND(NP, NZ) una asociación que significa qué produc- 
tos se pueden vender en cada zona, de tipo (m:m). Además, PREC(PTS) es el 
conjunto de precios de venta en pesetas de todos los productos en las diversas 
zonas. Tenemos un diagrama C/A de partida: 
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PREC (PTS) 


Asociemos los precios con los productos y zonas: 


VEND (-NP,NZ-,PTS) 


PREC (PTS) 


Suprimiendo rectángulos queda finalmente el diagrama RE/R: 


VEND (-NP,NZ—,PTS) 


El esquema de diseño es la relación: 
VEND(-NP, NZ-, PTS) 


sin otras condiciones adicionales. 
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REPRESENTACION DE ASOCIACIONES N-ARIAS 


La representación de relaciones n-arias mediante rectángulos nos ha permiti- 
do, como ya hemos visto, hacer representables en el diagrama RE/R las 
asociaciones binarias en que toman parte otras. Igualmente nos permiten repre- 
sentar asociaciones de grado superior a 2. Veamos esto. 


Sea R(X, Y, Z) una asociación ternaria entre las tuplas de los conjuntos 
AX, X1), BEY-, Y1) y C(EZ-, Z1), donde X, X1, Y, Y 1, etc., son atributos 
posiblemente compuestos. 


Representemos con un rectángulo el conjunto de tuplas de la relación R. 
Evidentemente, todos los valores de X, Y y Z existentes en R, deben existir 
también en A, B, y C. Por consiguiente, la representación en el diagrama tendrá 
tres asociaciones implicitas funcionales completas: 


1 


E EzZ=Z1) 


Esta representación es aplicable en general a asociaciones de cualquier grado. 
Toda asociación de este tipo puede así representarse gráficamente mediante un 
rectángulo y n asociaciones binarias, funcionales, completas e implicitas: 


R1 (-X1-,Y1) -+ | Rn (-Xn-,Yn) 
1 1 


Ae Xn) 


La cardinalidad en los extremos de las líneas que acaban en R, podrá ser, 
en general, una combinación cualquiera de n, m, c y 1, por ejemplo: (n:n:...:n), 
(mn. ma coles... Teto: 


Naturalmente, siguen siendo aplicables las reglas de transformación que ya 
hemos usado repetidas veces. 
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Ejemplo 1: 


Si tenemos un diagrama con cardinalidades (c:c:n), como el siguiente, se deduce 
que X e Y deben ser claves en R: 


A (-X-X1) C(=2=,21) 


Ejemplo 2: 
Si la cardinalidad fuera (1:n:n) podríamos agregar rectángulos. Sea: 


se transforma en: 


S (-X-,Y,Z,X1) 


(con S=AxR). 


Diagramas para diseño / 161 


S) 


REDUNDANCIA DE LA REGLA 
DE PROPAGACION DE CLAVES 


La Regla de Propagación de Claves no es estrictamente necesaria, pues puede 
substituirse por una combinación de las reglas de Definición de Claves y 
Agregación de Rectángulos. Para ello, basta con representar mediante rectángu- 
los también las asociaciones binarias funcionales. 


Por consiguiente, todas las asociaciones explícitas, tanto las binarias, funcio- 
nales o no, como las n-arias, se representarán con rectángulos, ligados por 
asociaciones binarias funcionales implícitas. 


Veamos cómo las Reglas de Definición de Claves y Agregación de Rectángu- 
los hacen redundante a la Regla de Propagación de Claves. Sea el diagrama: 


(donde C=A*R). 


Veamos ahora cómo llegar a este mismo diagrama sin aplicar la Regla de 
Propagación de Claves. Para ello transformamos la asociación explícita R en dos 
implícitas, representándola con un rectángulo: 


En este dibujo, aplicando la Regla de Definición de Claves, se deduce que X 
es clave en R(X, Y), o sea: REX-, Y). Además, agregando los rectángulos A y 
R queda: 
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con C(X, Y, Z)=A(X, Y)*R(X, Y). Vemos que hemos llegado al mismo 
diagrama que anteriormente. 


DEFINICION DE ENTIDADES 


Sea un diagrama RE/R, obtenido aplicando las reglas de transformación 
tantas veces como sea posible. Estará formado por los siguientes elementos: 


1) Rectángulos que representan relaciones n-arias (n=1, 2, 3, ...). 
2) Líneas entre ellos que representan asociaciones implícitas. 


Diremos que cada rectángulo representa un Tipo de Entidad o simplemente 
Entidad (con mayúscula). Las tuplas de la relación representada por un rectán- 
gulo representan ocurrencias de ese Tipo de Entidad o simplemente entidades 
(con minúscula). 


Diremos que una Entidad B depende de otra A si toda ocurrencia de B exige 
la existencia previa de una ocurrencia en A. Es decir, si entre ellas existe una 
asociación cuya cardinalidad no incluye el valor 0 en A. O también, si la 
cardinalidad de la asociación entre A y B es (a:b), donde a es 1 ó m y b 
puede ser cualquier valor (n, m, c, 1). 


Cabe distinguir tres clases de Tipos de Entidad: 
1) Entidades fuertes. También las llamaremos Entidades independientes o 
simplemente Entidades. 


Una Entidad es independiente cuando no depende de ninguna otra. Es 
decir, cuando todas las asociaciones entre ella y otras tienen en estas 
últimas una cardinalidad distinta de 1 ó m. 


Ejemplo 1: 


La Entidad representada por el rectángulo A del diagrama siguiente, puesto que 
todas sus asociaciones terminan en una cardinalidad que incluye el 0: 
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2) Entidades débiles. También las llamaremos Entidades dependientes. 
Son aquellas que dependen de otra y de ninguna más. 
Ejemplo 2: 
Son débiles las entidades A, Dl, D2, D3, B, C y G del diagrama: 


Dos entidades pueden ser interdependientes si una depende de la otra, 
y viceversa. Por ejemplo, las Entidades A y D3 del diagrama anterior. 

3) Entidades asociativas. Son las que dependen de otras dos o más. 
Ejemplo 3: 


La Entidad R siguiente es asociativa: 
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Entre las Entidades que dependen de otras hay un caso que merece ser 
destacado y que permite definir a una de ellas como subconjunto o subtipo de 
la otra. 


Sea una Entidad A con una clave X, y otra B asociada con A a través del atributo 
X con una cardinalidad (1:c). Diremos en este caso que B es una Entidad 
subordinada a A, o que B es un subtipo de A. 


El correspondiente diagrama sería: 


A (=X=, X1) 


B (=X=; Y1) 


Ejemplo 4: 


Sean las Entidades y relaciones siguientes: 


1) Empleados: EMP(-4E-, NE) 
AE: Identificador de empleado 
NE: Nombre de empleado 


2) Vendedores: VEN(-4E-, CO) 
CO: Comisión 

3) Vendedores con territorio: 
VET(-4T-, -NT-, -AE-) 
HT: Identificador de territorio 
NT: Nombre de territorio 


Supongamos que se cumplen las condiciones siguientes: 


e Todo vendedor es un empleado. Es decir, la Entidad VEN es un subtipo o 
clase de la Entidad EMP. 


e Todos los territorios tienen un vendedor asignado y sólo uno. Hay vende- 
dores que no tienen territorio porque actúan a través de concesionarios. 


Estas condiciones nos dan el diagrama: 
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EMP (-4fE—, NE) 


VEN (-4E-, CO) 


VET (-4T—, -NT- 
=4E-) 


Todas estas definiciones sobre distintos tipos de Entidades suelen tener 
un reflejo en aspectos semánticos de éstas. Aunque no siempre tenga que ser así, 
puesto que las definiciones dadas se basan en un aspecto puramente formal, son 
sin embargo éstas una buena ayuda para perfilar y precisar el significado 
intuitivo de las Entidades. 


ASOCIACIONES EXPLICITAS PARCIALES 
Diremos que una asociación explícita es parcial cuando no intervienen en ella 
todos los atributos de las claves de los rectángulos asociados. 


Cuando se dibuja un diagrama de diseño hay que tener cuidado de no incluir 
asociaciones explícitas parciales. 


Recordemos el significado de una asociación explicita. Sea el diagrama: 


A (-X1, X2-, X3) B (11, Y2-, Y3) 


Este diagrama significa que entre las tuplas de A y B existe una asociación 
explícita R. Puesto que las tuplas están identificadas por las claves, esto es 
equivalente a decir que R es una asociación entre las claves de A y B. Esto 
quedaría desvirtuado si R sólo existiera entre parte de los atributos de las claves, 
es decir, si R fuera una asociación parcial. Si éste fuera el caso, el diagrama 
anterior sería incorrecto. Habría que dibujar R entre otros rectángulos, distintos 
de A y B, que tuvieran como claves a los atributos de A y B implicados en R. 
Si no se hace así aparecerán dependencias transitivas en el diseño final, por lo 
que éste no estará normalizado. 
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Tomemos los siguientes conjuntos y asociaciones: 
PRO(NP): Números identificadores de Proveedores. 
ART(NA): Números identificadores de Artículos. 
C3(DA): Conjunto de descripciones identificadoras de Artículos. 


Rl: Pedidos (Asociación que expresa «Artículos pedidos a Provee- 
dores»). 


Supongamos que en cada pedido, además del identificador del Artículo y del 


Proveedor, figura también la descripción del Artículo. La asociación entre ésta y 
el pedido la llamaremos R2. Podemos representar esto en el diagrama: 


En este diagrama la asociación explícita R2 es parcial, pues la descrirción de un 
artículo, DA, va asociada realmente a su identificador, NA, y no a la clave 
completa del pedido, (NA, NP). Este diagrama es incorrecto y producirá un 
diseño no normalizado. En efecto, aplicándole las reglas de transformación 
obtenemos: 


En el esquema de diseño figurará por tanto la relación: R1 (-NA, NP-, DA). En 
esta relación se verifica las dependencias NA>DA, y DA>NA, cuyos anteceden- 
tes no son claves, y por tanto no está normalizada. 


En conclusión, al dibujar el diagrama hay que estar atento a las asociaciones 
explícitas entre rectángulos con claves compuestas para asegurarse de que no son 
parciales. 


PRODUCTO DE ASOCIACIONES 


Sea una asociación entre dos rectángulos A y B y otra entre B y C, explícitas, 
y de cardinalidades cualesquiera: 
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Definamos ahora una asociación ternaria, T, entre A, B y C, asociando a 
cada valor de A los de B que le corresponden en R, y a éstos los de C que le 
corresponden en $. 


Ejemplo 1: 
Supongamos los valores siguientes: 


Valores R Valores S Valores 
de Á (A, B) de B (BE) de C 


1 (Q, a) a (b, A) A 
2 (Q, b) b (b, C) B 
3 (4, b) Cc (d, C) 6 
4 (4, c) d D 
5 


La Asociación T sería: 


Evidentemente, T=R+*S. 


Llamaremos producto de dos asociaciones, R y S, con un rectángulo común, 
B, como en el diagrama anterior, a otra asociación, P, entre los elementos de A 
y C, que asocia a cada elemento de A los de C que, según S, están asociados a 
los de B que están a su vez asociados, según R, al elemento considerado de A. 
Es decir, asociamos a cada elemento de A los de C que se obtienen recorriendo 
el camino A-R-B-S-C del diagrama. O lo que es igual: P=T[A, C]. 


Ejemplo 2: 
Para los valores del ejemplo anterior tenemos: 


P 


a»a>|a 


A 
2 
2 
4 
4 
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La cardinalidad de P está condicionada por la de los factores, R y S. Así en 
el extremo de C la cardinalidad de P puede tomar los valores indicados en la 
tabla siguiente: 


Cardinalidad del Producto 


1 


n c 
" 
: 
Ejemplo 3: 


Así, si R es (1:m) y S es (c:n), la cardinalidad del producto de ambas vendrá 
dada por c-1=c y m- n=(n, m, c, 1 ó 0). Tomando los valores más generales, la 
cardinalidad sería (c:n). 


Como la asociación P es obtenible a partir de R y S, es redundante con 
ellas, por lo que no deberá figurar en el esquema de diseño. 


La operación de multiplicar asociaciones puede definirse con más de dos 
factores si recorremos un camino del diagrama RE/R de más de dos tramos. 


Ejemplo 4: 
Sean las asociaciones implícitas siguientes: 


Si recorremos el camino A-R-B-S-C-T-D, asociamos a cada elemento de A todos 
los de B que le correspondan en R, a éstos todos los C que le correspondan en 
S, etc. Obtendremos una relación de asociación, Q: 

Q(X, Y, Z, W)=A[X]*R(X, Y) * B[Y]*S(Y, Z)*CIZ]* T(Z, W)x D[W] 
Como (A[X]*R(X, Y)=R(X, Y) y (B[Y]*S(Y, Z)=S(Y, Z)), etc. queda: 

Q(%, Y, Z, W)=R(X, Y)*S(Y, Z)x*T(Z, W) 


Esta relación, o cualquiera de sus proyecciones, es redundante. 
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Siempre que en un diagrama hay asociaciones redundantes, su dibujo presen- 
ta bucles (prescindiendo de las flechas, pues éstas no indican sentido, sino sólo 
cardinalidad). El reciproco no es cierto. 


Puede haber bucles sin que haya redundancia de asociaciones. Esto depende 
del significado de éstas. Si el bucle se debe a que hay alguna asociación 
redundante, hay que romper el bucle, si es posible, eliminándola. A veces, dentro 
de un bucle redundante puede eliminarse una u otra asociación, lo que obliga a 
elegir una de ellas. Para ello puede ser conveniente dibujar varios diagramas, 
con las diversas alternativas, y elegir aquel que produzca el mejor diseño final. 
Esto será más fácil de realizar si el proceso de diseño se apoya en alguna 
herramienta mecanizada. En este tipo de decisiones, la experiencia y buen juicio 
del analista serán el mejor consejero. 


Veamos algunos ejemplos. 


Ejemplo 5 


Sea el diagrama RE/R siguiente: 


A(- Papa 


Vemos que hay varios bucles. Por ejemplo, (A-R-B-S-C-T-D-P-A), (A-R-B-S-C- 
T-D-Q-A), (B-S-C- Q-B), etc. Supongamos que Q=R(X, Y) *S(Y, Z)*T(Z, W). 
Por consiguiente, al ir de A a D por el camino (A-R-B-S-C-T-D) se obtiene el 
mismo resultado que por el camino (A-Q-D). Supongamos que ocurre lo mismo 
yendo por el camino (A-P-D). Es decir, que se obtienen los mismos valores de W 
asociados a un valor cualquiera de X yendo de A a D por cualquiera de estos 
caminos. En resumen, o bucles son debidos a que las asociaciones Q y P son 
redundantes con R, S y T 


Eliminándolas queda el siguiente diagrama: 
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Ejemplo 6: 

Sean los siguientes conjuntos: 
PRO(NP): Números identificadores de Proveedores. 
ART(NA): Números identificadores de Artículos. 
CLI(NC): Números identificadores de Clientes. 
C1(DA): Descripciones de Artículos. 


Y sean las siguientes asociaciones entre ellos: 
COM=Pedidos de Compras (conjunto de Artículos que hemos pedido a 
nuestros Proveedores). 

VEN: Pedidos de Ventas (conjunto de Artículos que nos han pedido nuestros 
Clientes). 

CLP: Conjunto de Clientes que nos han comprado Artículos suministrados 
por un determinado Proveedor. 

R1: Descripciones de los Artículos en los Pedidos de Compras. 


Supongamos que el diagrama de partida es: 


R1 


PRO (NP) 
COM (NP,NA) 
CLP (NC,NP) 


VEN (NC,NA) 
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Hay varios bucles en este diagrama. Consideremos primero el bucle (C1-R2-ART- 
COM-R1-Cl1). 


R1 (NP, NA, DA) y R2 (-NA-, -DA-—) son redundantes, pues R2=RI1[NA, DA]. 
La causa de este bucle es que la asociación explícita R1 es parcial, es decir, no 
debieran intervenir en ella realmente las claves completas de los rectángulos 

articipantes, pues la descripción del Artículo no debe ir asociada al Pedido 
lane: (NP, NA), sino solamente al Artículo (NA). En resumen, R1] contiene la 
misma información que R2 y podemos eliminarla del diagrama. Como además 
R2 es de cardinalidad (1: 1)'se pueden agregar los rectángulos Cl y ART. Nos 


queda: 


CLP (NC,NP) 


Evidentemente, los clientes que compran los artículos suministrados por un 
proveedor determinado se obtienen entrando en el diagrama por proveedor y 
recorriendo el camino PRO-COM-ART-VEN-CLI, o también, entrando por pro- 
veedor y recorriendo el camino PRO-CLP-CLI. Es decir, CLP es redundante con 
VEN y COM. O dicho de otro modo: CLP(NC, NP) =P(NC, NP) (VEN x* COM). 


Eliminando CLP, el diagrama sin redundancias será: 


VEN (NC,NA) COM (NP,NA) 


Supongamos ahora que es posible que algunas empresas que son Proveedores 
nuestros también sean Clientes. Esto lo reflejaremos en el diagrama mediante una 
asociación entre los conjuntos CLI y PRO. La llamaremos CLIESPRO («Cliente 
es Proveedor») y nos asociará el identificador de un Proveedor con el de un 
Cliente cuando correspondan a una misma empresa. El diagrama quedará: 
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CLI (NC) 
VEN (NC,NA) 


ART (-NA—,DA) PRO (NP) 
COM (NP,NA) 


CL IESPRO (-NC-—, —-NP-) 


En este diagrama hay bucles, pero no redundancias. Es interesante observar que 
puede aparecer aquí una condición de integridad que no es expresable en el 
diagrama, ni tampoco como una dependencia de las estudiadas, que es la 
siguiente: probablemente, una empresa no nos comprará Artículos que ella misma 
nos suministre. Es decir, que (VEN * COM * CLIESPRO) es una relación vacía. 
Es posible, sin embargo, que en alguna ocasión se viole esta condición. Por 
ejemplo, si un Proveedor se quedare sin existencias de un Artículo que nos vendió 
previamente y los necesitare urgentemente, podría decidir recomprárnoslos. Esta 
consideración puede hacer aconsejable no incluir esta condición en el esquema 
final de diseño. 


En conclusión, si al dibujar el diagrama aparecen bucles, hay que analizarlos 
para determinar si se deben a la presencia de asociaciones redundantes o no, y 
en caso afirmativo suprimirlas si es posible. Si no se suprimen, el diseño final 
que se obtenga estará probablemente no normalizado (posiblemente contendrá 
dependencias transitivas). 


DEPENDENCIAS PLURALES 


Puede ocurrir también que una asociacón ternaria (o de grado superior) se 
pueda descomponer en otras. 


Consideremos el diagrama: 
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S 


Sean S=R[X, Y] y T=R[Y, Z]. Si R es descomponible en S y T, será R=S+*T. 
Entonces, el diagrama anterior sería equivalente a: 


Ejemplo 1: 
Supongamos los conjuntos de valores siguientes: 
VEN(NV): Números identificadores de Vendedores. 


ART(NA): Números identificadores de Artículos. 


ZON(NZ): Números identificadores de las Zonas geográficas en que se divide 
el país a efectos de gestión del mercado. 


Sea una asociación ternaria, AUT(NV, NA, NZ), que indica qué vendedores están 
autorizados a vender determinados artículos en las distintas zonas. El diagrama 


RE/R será: 


VEN (NV) 


AUT (NV,NA,NZ) 


La relación VENART=AUT[NV, NA] nos dice cuáles son los artículos que cada 
vendedor está autorizado a vender. La relación VENZON=AUT[NV, NZ] nos 
dice cuáles son las zonas asignadas a cada vendedor. 


Supongamos que estas dos asociaciones son independientes, es decir, que los 
artículos asignados a un vendedor son independientes de sus zonas. Así, si por 
ejemplo el vendedor V1 vende los artículos Al y A2, y vende en las zonas Zl y 
Z2, todas las combinaciones posibles de artículos y zonas deben estar autorizadas 
para este vendedor: (Al, Z1), (A1, Z2), (A2, Z1) y (A2, Z2). Esto equivale a decir 
que en la relación AUT(NV, NA, NZ) se verifican las DPs: (NV>NZ) y 
(NV>NA). Por tanto, AUT será descomponible en VENART y VENZON, y 
será semánticamente más correcto dibujar el diagrama así: 
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ART (NA) VEN (NV) ZON (NZ) 
VENART (NA,NV) VENZON (NV,NZ) 


Si una asociación es de grado superior a 3, pueden presentarse DPs embe- 
bidas. 


Ejemplo 2: 
Supongamos que en el ejemplo anterior cada vendedor cobra un porcentaje de 
comisión que depende de cada artículo y zona. El correspondiente diagrama RE/R 


será: 
ART (NA) VEN (NV) ZON (NZ) 


COM (NV,NA,NZ) 


POR (PC) 


Propagando la clave queda: 


COM (-NV,NA,NZ-,PC) 


Como en el caso anterior, si suponemos que los artículos asignados a un vendedor 
son independientes de las zonas en que éste trabaja, la asociación ternaria entre 
(NV, NA, NZ), se compone de dos binarias independientes. Así, si el vendedor 
V1l puede vender los artículos Al y A2, y en las zonas Z1 y Z2, entonces este 
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vendedor podrá recibir comisiones por todas las combinaciones de los artículos 
y zonas en que trabaja, es decir: 


COM NV NA  NZ PE 


Pero en este caso no existe una DP explícita, sino embebida, entre (NV>NA | NZ) 
en la relación COM, y, por tanto, ésta no es descomponible. Es una condición 
no expresable en el diagrama. 


En resumen, cuando al dibujar un diagrama se encuentra una asociación de 
grado superior a 2, conviene examinar si tiene DPs que permitan descomponerla. 


OTROS TIPOS DE DEPENDENCIAS 


Sea una asociación R como la representada en el diagrama siguiente: 


R1 (-X1-,Y1) 


R(X,X1,X2,... Xn) 


Supongamos que los valores de un Xi asociados en R a un valor de X son 
independientes de los de otros Xj asociados al mismo valor de X. O lo que 
es igual, todas las combinaciones de valores asociados a un X dado son válidas. 
En este caso existe una DJ(X>X1|X2| ---| Xn) en la relación R, y por tanto ésta 
es descomponible en sus proyecciones sobre (X, X1), (X, X2), ..., (X, Xn). Es 
entonces más correcto, para representar el significado de los datos, dibujar el 
diagrama como sigue: 
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Análogamente, podrían presentarse en R dependencias yuncionales, generali- 
zadas o de otros tipos. Veamos algunos ejemplos de condiciones de integridad 
no expresables como dependencias. 


Ejemplo 1. Representación de un grafo: 


En el siguiente diagrama RE/R representamos la estructura de datos de un grafo 
plano. Este tipo de estructuras se aplica a todos los problemas que pueden 
representarse mediante estos grafos (por ejemplo, redes PERT, listas de materiales, 
organigramas funcionales, etc.). 


Sea un grafo bidimensional dirigido, con un arco como máximo, en cada 
dirección, entre dos nodos. Numeremos todos los nodos. Sea N(X) el conjunto 
de todos los números de los nodos del grafo. Cada arco es una asociación entre 
el nodo origen y el nodo destino. Tendremos pues el diagrama C/A siguiente: 


n n 


En este diagrama la asociación A entre nodos representa los arcos del grafo. Como 
es una asociación entre elementos del mismo conjunto (el N(X)), hay que calificar 
el atributo X para distinguir los dos papeles diferentes que juega en A(X.O: nodo 
origen; X.D: nodo destino). 


Transformemos la asociación explícita A, de cardinalidad (n : n), en dos implícitas 
funcionales completas. Tendremos así el diagrama RE/R: 


( 


A (X.O, X.D) 


Diagramas para diseño / 177 


(Como en este diagrama las asociaciones implícitas son parciales, hay que indicar 
explícitamente en las líneas los atributos a que se refieren, como ya se ha 
comentado cuando se describieron las características de las asociaciones implícitas). 


Naturalmente los nodos y arcos pueden tener atributos a su vez. Sean B los 
atributos de los nodos y C los de los arcos. El diagrama RE/R para representar 
un grafo quedará finalmente: 


El esquema relacional de diseño será: 


Relaciones: N(-X-, B), A(X.O, X.D-, C). 
Condiciones: A[X.0] <N[X]; A[X.D]<N[X]. 


Ejemplo 2. Grafo conexo: 


Supongamos ahora que queremos representar un grafo conexo. Es decir, en el 
que no haya nodos sueltos. Tendremos que todo nodo participa en algún arco. 
El esquema relacional de diseño será: 


Relaciones: NEX-, B), A(EX.O, X.D-, C). 
Condiciones: N[X]=(A[X.0] u A[X.DJ). 


Obsérvese que la condición anterior no es expresable ni como una dependencia 
ni como una condición de integridad de referencia. 


Ejemplo 3. Arbol: 


Supongamos ahora que queremos representar un árbol. Todo nodo cuelga de 
otro, excepto el raíz, que no cuelga de ninguno. El diagrama RE/R será: 
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Como una de las asociaciones implícitas tiene cardinalidad c, su correspondiente 
atributo, (X.D), tiene que ser clave en A. Por tanto, el esquema de diseño será: 


Relaciones: N(-X-, B), A(X.O, -X.D-, C). 
Condiciones: A[X.0] <N[X]; A[X.D]<N[X]. 


Además de las condiciones de integridad anteriores, deberá cumplirse que en 
A[X.D] deben aparecer todos los nodos de N[X], menos el raíz (o sea, que Á 
deberá tener una fila menos que N). De nuevo esta condición de integridad no es 
expresable como uno de los tipos de dependencias estudiados anteriormente 
ni como integridad de referencia. 


Además tiene que cumplirse otra condición de integridad: que no haya bucles en 
el grafo. Tampoco esta condición es expresable mediante los tipos de condiciones 
hasta aquí estudiados, y plantea además una situación interesante, pues la 
detección de bucles implica el uso de operaciones de clausura, es decir, yunciones 
reiterativas aplicadas un número variable de veces, lo que no es directamente 
expresable en álgebra relacional. 


En resumen, al dibujar el diagrama hay que estar atento a las asociaciones 
de grado superior a 2, para analizar si pueden contener Dependencias Plurales 
o de otro tipo que permitan descomponerlas en otras más simples, y hacerlo así 
si es posible. 


USO DE LOS DIAGRAMAS RE/R EN EL DISEÑO 
DE ESTRUCTURAS IMS 


El IMS (Information Management System) es un sistema de Bases de Datos 
no relacional. Permite diseñar esquemas conceptuales en red con presentación 
jerárquica. Estos párrafos van dirigidos a los lectores interesados en el IMS. 


La construcción de diagramas RE/R nos proporciona un medio de expresión 
o lenguaje para representar los modelos conceptuales de datos. Puede parecer 
entonces que estos diagramas serían aplicables tanto a la obtención de esquemas 
de diseño relacionales, según hemos visto, como a los de otros tipos, por ejemplo 
esquemas de datos IMS. Sin embargo, no es totalmente así. 


En general, para que así fuera, el lenguaje en el que expresemos el modelo 
conceptual de datos (el diagrama RE/R en nuestro caso), debería tener al menos 
la misma potencia expresiva que el del Sistema de Base de Datos que considere- 
mos (en nuestro caso el IMS). Esto no es así si comparamos el lenguaje de un 
diagrama RE/R con el del modelo conceptual IMS, lo que se debe al diferente 
enfoque de las construcciones básicas de datos de ambos. 


En un diagrama RE/R uno de los elementos básicos, el rectángulo, representa 
conjuntos de valores, por lo que no pueden éstos repetirse. Sin embargo, en un 
diagrama conceptual IMS, un rectángulo representa un conjunto de ocurrencias 
de un determinado tipo de segmento, sin tener en cuenta los valores que éstos 
contienen, por lo que es posible que estos conjuntos contengan valores repetidos 
(segmentos sin campo de secuencia o con campo de secuencia múltiple). 


Veamos algún ejemplo para concretar estas ideas. 
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Ejemplo 1: 


Sea el siguiente modelo conceptual IMS: 


Supongamos que el segmento padre A contiene los campos (X, C) y el hijo B los 
campos (Y, D), y que los atributos X e Y, posiblemente compuestos, son los 
respectivos campos de secuencia. Supongamos además que son campos de secuen- 
cia únicos, es decir, que los valores de X no se repiten en ninguna ocurrencia del 
segmento A, y los de Y no se repiten en las ocurrencias de B que cuelguen de un 
mismo A. Esta situación sí es representable en un diagrama C/A (y por tanto en 


un diagrama RE/R). El diagrama C/A sería: 
Al A2 
R3 (C) R2 (Y) 
m m n 


R1 (X) 
(R1, R2, R3 y R4 son los conjuntos de valores de X, Y, C y D, respectivamente). 


Obsérvese que la asociación A2, entre X e Y, es de cardinalidad (m:n), pues un 
valor determinado de Y puede repetirse bajo distintos valores de X. 


El diagrama anterior se transforma en el siguiente diagrama RE/R (en el que 
aparece una asociación de asociaciones, la A3): 
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Y, por tanto, el esquema relacional de diseño equivalente a la estructura IMS será: 


Relaciones: A(X-, C), B(EX, Y-, D). 
Condiciones: B[X]<A[X]. 


Ni este esquema de diseño ni el diagrama RE/R nos permiten representar la 
estructura anterior de IMS en el caso de que el campo de secuencia Y sea múltiple 
(o sea, si Y puede tomar valores repetidos debajo de una ocurrencia dada de A), 
pues no es posible identificarlas unívocamente por su contenido. Lo mismo 
ocurriría si el segmento de tipo B no tiene campo de secuencia. 


Ejemplo 2: 


Veamos cómo se construiría el diagrama RE/R equivalente a una estructura IMS 
con una relación lógica. Sea esta estructura la siguiente: 


(Padre 


(Padre 
lógico) 


físico) 


En el diagrama anterior suponemos que A es el padre fisico de C, y B es su padre 
lógico. 

Atributos de A: A(X, X1). 

Atributos de B: B(Y, Y]1). 

Atributos de C: C(I, W, Z). 

X: Campo de secuencia único de A. 

Y: Campo de secuencia único de B. 

I, W, Z: Datos de intersección en C. 
Supongamos que las ocurrencias C, vistas desde sus padres, Á y B, tienen campos 
de secuencia únicos. Estos campos, normalmente, serán los de los padres, es decir, 


entrando por A el campo de secuencia será Y (pues C contiene los campos Y, I, W 
y Z), y entrando por B será X (C contiene los campos X, I, W y 2). 


El diagrama C/A equivalente será: 


A1 
n 
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El diagrama RE/R será: 


d ER 


C (-X, Y-,1,W,Z) 


El esquema relacional de diseño será: 


Relaciones: A(X-, X1), BEY>, Y1), CEX, Y>, 1, W, Z). 
Condiciones: C[X]<A[X], C[Y]<B[Y]. 


Ejemplo 3: 


En general, sin embargo, en IMS, aunque C tenga campos únicos de secuencia, 
no tienen que ser necesariamente las claves concatenadas de los padres, sino que 
pueden ser campos cualesquiera de C, por ejemplo, el campo de secuencia 
entrando por A podría ser W, y entrando por B, Z. Esto permite en IMS que 
pueda existir más de una ocurrencia del hijo lógico C bajo las mismas ocurrencias 
de los padres (es decir, más de un C para una misma pareja (A, B) dada). 


Construyamos el diagrama RE/R para este caso. El diagrama C/A de partida será: 


A1 A2 


A3 A4 


Lo transformamos en: 
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Lo transformamos finalmente en: 


C (-XW-,-Y,Z-, 1) 


Esquema relacional de diseño: 


Relaciones: A(EX=, X1), B(=Y>, Y1), CEX, W-, —Y, Z-, D. 
Condiciones: C[X]<A[X], C[Y]<BL[Y]. 


En resumen, es posible construir un diagrama RE/R equivalente a un modelo 
conceptual IMS si en éste todos los tipos de segmentos tienen campos «únicos» 
de secuencia. En caso contrario, no es posible, y, por consiguiente, el diagrama 
RE/R no será una buena técnica de ayuda para el diseño. En la práctica, sin 
embargo, es improbable que estos casos se presenten. Si así fuera, podrían 
evitarse buscando atributos adicionales que puedan emplearse como identificado- 
res (o incluso generándolos en los programas de aplicación). 


EL MODELO DE DATOS E/R (DE ENTIDADES/RELACIONES) 


El modelo conceptual de datos en un diagrama E/R se construye con los 
elementos siguientes: 


e Rectángulos con un nombre. Cada rectángulo representa un conjunto de 
objetos sobre los que queremos guardar datos homogéneos (por ejemplo: 
empleados, artículos, etc.). 


e Rombos con un nombre. Cada rombo representa una asociación entre los 
elementos de dos o más rectángulos que se unen con líneas al rombo. En 
los extremos de estas líneas se indica la cardinalidad de la asociación. 


e Ovalos con un nombre. Cada óvalo representa un conjunto de valores 
simples, es decir, atributos. Cada óvalo se une con líneas a los rectángulos 
o rombos para indicar cuáles son los atributos de éstos. 


Estos diagramas se llaman diagramas E/R (y también diagramas de Chen). 
Como vemos no se exige en este modelo de datos que los elementos de un 
conjunto representado por un rectángulo o un rombo tengan algún atributo 
identificador o clave. Por ello, las observaciones que decíamos al intentar 
representar estructuras IMS con diagramas RE/R son también aplicables aquí. 
Es decir, todo diagrama E/R en el que todos sus rectángulos y rombos tengan 
clave es representable con un diagrama RE/R equivalente. Además, dada la 
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similitud entre los elementos básicos de ambos tipos de diagrama, el paso de 
uno a otro es inmediato. Sin embargo, si hay en el diagrama E/R rectángulos o 
rombos sin clave, no es posible construir un diagrama RE/R equivalente. En este 
caso, como decíamos al hablar de IMS, lo aconsejable, si es posible, es añadir 


nuevos atributos que puedan usarse como identificadores (o generarlos en los 
programas de aplicación). 


EJERCICIOS PROPUESTOS 


En los ejercicios siguientes, para simplificación de los dibujos, dejaremos a veces las 
asociaciones explícitas sin nombre. En este caso indicaremos que son explícitas adjuntán- 
doles el signo £. También, por la misma razón, se omitirán a veces los nombres de los 
conjuntos de valores representados en los rectángulos. 


1) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 
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4) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 
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7) Obtener las entidades definidas por el diagrama siguiente y decir de qué tipo son: 
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9) Partimos del diagrama siguiente. Además de las asociaciones representadas en él hay 
otras dos: S y T. La primera entre los elementos de C1 y R, con cardinalidad (1 : m). 
L a segunda entre los elementos de C2 y T, con cardinalidad (m:m). Representar S y 
T en e diagrama, obtener el esquema de diseño y decir de qué tipo son las Entidades 
obtenidas: 


10) Sean dos relaciones, A(X, Y, Z) y B(X, Y, W). La asociación implícita entre A y B, 
según X, es de cardinalidad (m:1); según Y, es de cardinalidad (m:c), y según (X, 
Y), es de cardinalidad (m:c). Comprobar que estas cardinalidades no son contradicto- 
rias y poner un ejemplo de extensiones de ambas relaciones que las cumplan. 


11) Transformar el diagrama siguiente: 


12) Transformar el diagrama siguiente: 
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13) Dado el siguiente diagrama, decir si la asociación explícita R3 es el producto de las 
asociaciones R1 y R2. 
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16) En el diagrama siguiente, hallar las cardinalidades posibles de la asociación implícita 
entre A y C y decir si es redundante: 


17) Sea el diagrama siguiente: 


Supongamos que el bucle (R-S-T) se debe a que la asociación T es redundante con 
R y S. ¿Puede afirmarse también que R es redundante con S y T y que S es 
redundante con R y T? ¿Cuál de las tres asociaciones, R, S o T, es preferible eliminar 


en el diagrama? 
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Método y ejemplos 
de diseño 


En el capítulo anterior hemos expuesto un método para construir un diagra- 
ma RE/R y obtener a partir de él el esquema de diseño. Sin embargo, el diseño 
de un Esquema Conceptual de datos es una tarea más amplia que la obtención 
del diagrama RE/R. En este capítulo vamos a empezar tratando de situar la 
posición del método propuesto dentro del proceso global de diseño. Seguiremos 
con un resumen de aquél, y luego expondremos algunos ejemplos de aplicación. 


FASES DE DISEÑO 


Vamos a considerar en el proceso de diseño las siguientes Fases y actividades: 


Fase I 


Obtención del Esquema Conceptual de datos. Suele designarse esta fase como 
Diseño Lógico. Incluye las actividades siguientes: 


— 1.1). Definir el objetivo del diseño. 


Esta labor debe realizarla fundamentalmente la Dirección. 


— 1.2). Definir los datos a incluir en el Modelo Conceptual. 


Aquí hay que decidir qué datos hay que incluir en el modelo, y definir su 
significado. Para llevar a cabo esta actividad el analista tendrá que 
obtener información de los usuarios de los datos, frecuentemente a nivel 
directivo. 


La definición precisa del significado de los datos es probablemente la 
labor más importante y difícil del diseño. Esperamos que algo de esto 
pueda apreciar el lector cuando examine los ejemplos de este capítulo. 
Por ello es útil ir construyendo ya a lo largo de esta actividad el diagrama 
RE/R. De esta forma disponemos de un soporte documentado de las 
informaciones y decisiones que se vayan tomando. Además de ser una 
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buena herramienta para afinar con precisión el significado de los datos, 
también lo es para formalizar y facilitar la comunicación con los usuarios 
y dirección. 


1.3). Obtener el Esquema Conceptual de datos: 


Al final de la actividad anterior, como consecuencia de las definiciones 
obtenidas en ella y aplicando las reglas de transformación descritas en el 
capítulo precedente, se obtiene el diagrama RE/R, que representa un 
primer Esquema Conceptual de datos. Este diagrama se traduce directa- 
mente a un esquema de diseño formado por relaciones y condiciones de 
integridad. 


El método de diseño propuesto se aplica plenamente en la realización de 
esta actividad. 


1.4). Refinar el Esquema de diseño. 


El modelo de datos representado por el diagrama RE/R anterior puede 
necesitar algunas modificaciones o adiciones que se introducirán en las 
siguientes actividades: 


— Añadir a las condiciones de integridad obtenidas directamente del 
diagrama las que no se hayan podido expresar o utilizar en su cons- 
trucción. 


— Repasar y validar con usuarios el diagrama final obtenido. 


Comprobar que las Entidades obtenidas corresponden a conceptos 
lógicos y naturales en el mundo real representado por nuestro modelo 
de datos. Analizar si hay discrepancias. Estas pueden deberse a cardina- 
lidades especificadas incorrectamente. 


— Prever si puede haber cambios futuros en la estructura de datos que 
afecten al diseño. 


Analizar cómo repercutirian en él y la conveniencia de modificarlo 
ahora para que sean fácilmente asimilables cuando se produzcan. 


Por ejemplo, supongamos que tenemos una asociación de cardinalidad 
(1 :m) entre Vendedores y Productos que por cambios en la política 
comercial de la empresa pueda ser en el futuro (m : m). Sería convenien- 
te definirla ya así en el diagrama, lo que podría dar lugar a alguna 
relación más en nuestro esquema de diseño. 


— Incluir la posibilidad de valores nulos. 


Las reglas aplicadas en la obtención del diagrama RE/R producen un 
diseño en que no hay columnas con valores nulos. Si nuestro Sistema 
Relacional es capaz de tratar estos valores, podría ser ventajoso consi- 
derarlos. Comentaremos con más detalle este punto en otro apartado, 
más adelante. 


— Definir qué claves van a ser Primarias. Definir las reglas de Inserción, 
Actualización y Borrado para el mantenimiento de las condiciones de 
Integridad de Referencia. 
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Fase Il 


Reajustes al diseño en función de su utilización. 
Suele conocerse esta Fase como Diseño Físico. 


El diseño obtenido como consecuencia de las actividades anteriores se basa en 
la estructura e interrelaciones de los datos, sin tener en cuenta qué uso se va a 
hacer de ellos. Para analizar este punto vamos a clasificar las formas de 
utilización de los datos en tres tipos: 


1) Utilización de los datos por programas de ejecución frecuente, normal- 
mente escritos por programadores profesionales con experiencia. 


2) Utilización por programas que se ejecutan un número limitado de veces. 
3) Utilización por usuarios finales mediante lenguajes de consultas. 


En el primer caso prevalecerán los requerimientos de buen rendimiento (por 
ejemplo, medido en número de acceso a disco). En el segundo será más 
importante una productividad alta en programación y pruebas. En el tercero será 
más importante la facilidad de uso. En caso de tener varios tipos de utilización 
tendremos que satisfacer simultáneamente requerimientos de uno y otro tipo, lo 
que puede llevar a criterios de diseño contradictorios, entre los que habrá que 
buscar un equilibrio. 


No incluimos aquí una discusión de cómo repercuten los requerimientos de 
rendimiento en el diseño físico, pues esto va íntimamente ligado al Sistema 
Relacional que utilicemos. En general, nos llevará a definir índices o vías de 
acceso adicionales en disco para las búsquedas más frecuentes. Un cierto grado 
de redundancia de datos (desnormalización), que siempre debe estar bien contro- 
lada y documentada, puede favorecer el rendimiento de operaciones de consulta, 
en detrimento de las de actualización. Por otra parte, un diseño normalizado 
favorecerá, en general, a la productividad en desarrollo de programas. 


Si la utilización va a ser fundamentalmente para consultas de usuarios finales, 
podemos facilitarles el uso de los datos mediante acciones como las siguientes: 


1) Evitar el abuso de códigos. Así, por ejemplo, en vez de usar códigos de 
provincias, utilizar sus nombres. 


2) Incluir campos precalculados. 
3) Incluir vistas con las yunciones de uso más frecuente predefinidas. 


Esta lista sólo pretende mostrar algunos ejemplos. En general, conseguimos 
mayor facilidad de uso a costa de una mayor redundancia de datos. 


INCORPORACION DE VALORES NULOS 


Las reglas de transformación de diagramas que hemos visto y que nos 
permiten llegar al diagrama RE/R final no tienen en cuenta la posibilidad de que 
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existan valores nulos. Sin embargo, si el sistema los permite, podríamos dismi- 
nuir el número de relaciones del esquema de diseño si incluyéramos algunas 
columnas que admitieran estos valores. 


Para conseguir esto vamos a modificar la regla de Agregación de Rectángu- 
los, generalizándola como sigue: 


Sean dos rectángulos, A(X, Y, Z) y B(X, Y, W), con atributos comunes X e Y, 
posiblemente compuestos. Supongamos que X es una clave de A y de B, y que la 
asociación implícita entre A y B, según X, es de cardinalidad (c:c), o (c:1), o (1:10). 
Entonces A y B pueden agregarse, substituyéndolos por un solo rectángulo C 
obtenido como yunción externa entre A y B. Todas las asociaciones en que 
intervienen A y B se aplican también a C. La clave de C es X. 


Veamos el caso gráficamente. Sea el diagrama: 


B (-X-,Y,W) 


Sea C el resultado de obtener la yunción externa, según X, entre A y B. 
Entonces el diagrama anterior es equivalente a: 


C (-X-.Y.A,Z Y.B,W) 


En C todos los atributos, excepto X, pueden tomar valores nulos. 


Si la cardinalidad de la asociación entre A y B fuera (1: c), los atributos de 
C que podrían tomar valores nulos serían los procedentes de B, es decir, Y.B y 
W. Si la cardinalidad entre A y B fuera (1:1), ningún atributo de C tomaría 
valores nulos. Este último es el caso que se incluyó en la Regla de Agregación 
de Rectángulos del capitulo anterior. 


Por tanto, una vez obtenido el diagrama RE/R le aplicaremos la nueva Regla 
de Agregación si consideramos conveniente incluir algunas columnas con la 
posibilidad de tomar valores nulos. Estos valores pueden ser complicados de 
entender y manejar para los usuarios finales, por lo que su inclusión en el diseño 
debe ser discrecional, según los requerimientos de uso previstos para los datos. 
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Ejemplo: 
Sean los conjuntos siguientes: 


C1(DND): Conjunto de valores del DNI (Documento Nacional de Identidad) 
de los empleados de una empresa. 


C2(NOM): Conjunto de los nombres de los empleados. 
C3(SEX): Sexo de empleado. 


C4(MAT): Conjunto de números que representan días de permiso por materni- 
dad concedidos a algunas empleadas. 


El diagrama C/A de partida será: 


m 


Se transforma en el siguiente diagrama RE/R: 


EMP (-DNI-,NOM,SEX) 
PER (-DNI-,MAT) 


Aplicándole la Regla de Agregación generalizada queda: 
EMP (-DNI-,NOM,SEX,MAT) 


1) Relación: EMP (DNI, NOM, SEX, MAT), donde MAT puede tomar 
valores nulos. 


El diseño final es: 


2) Condiciones de integridad: MAT sólo puede tomar valores no nulos si 
SEX="E”. 


194 / Método y ejemplos de diseño 


S 


OBTENCION DEL ESQUEMA RELACIONAL DE DISEÑO 


Vamos a resumir aquí el proceso de obtención del diagrama RE/R y del 
esquema de diseño que se expuso en el capítulo anterior. 


1) 


2) 
3) 


4) 


5) 
6) 


7) 


8) 


9) 


10) 


Representar con rectángulos los conjuntos de valores. Estos pueden ser 
simples (relaciones unarias) o compuestos (relaciones n-arias). 


Los diseñadores que empiecen a usar el método representarán normal- 
mente conjuntos de valores del grado más sencillo posible. Al ir adqui- 
riendo experiencia representarán conjuntos de grado más complejo, 
dibujando ya directamente en el diagrama de partida algunas entidades 
con todos o parte de sus atributos. 


Representar con rectángulos todas las asociaciones explícitas entre con- 
juntos, tanto las binarias, funcionales o plurales como las n-arias. 


Representar con rectángulos las asociaciones explícitas entre asocia- 
ciones. 


Representar con líneas entre los rectángulos todas las asociaciones. 
Todas ellas serán implícitas. Representar la cardinalidad de las asociacio- 
nes sobre las líneas respectivas. 


Comprobar que no se han definido asociaciones explícitas parciales. 


Aplicar la regla de Definición de Claves a las asociaciones implícitas 
(m0), (m«Didsc) 0 (11D). 


Comprobar si alguna de las relaciones n-arias representadas en los 
rectángulos no está normalizada. Esto será así si hay dependencias que 
no sean consecuencia de las claves. Descomponer estas relaciones si es 
posible. 


Comprobar si alguna relación es producto de otras. En este caso 
suprimirla si es posible. 


En esta etapa del proceso hemos llegado ya a obtener un diagrama RE/R 
inicial, válido para obtener un esquema de diseño, aunque probablemente 
demasiado prolijo. Conviene transformarlo para simplificarlo. Este es el 
objetivo de los siguientes pasos. 


Aplicar reiterativamente mientras sea posible las Reglas de Agregación 
de Rectángulos (a las asociaciones (1: 1)) y de Supresión de Rectángulos 
(en las asociaciones (m: 1). 


Al aplicar estas reglas el número de rectángulos disminuye o se mantiene 
igual, por tanto, es un proceso finito. 


Cuando ya no se pueda transformar más el diagrama RE/R aplicando 
reglas, habremos llegado a su forma definitiva, de la que obtendremos el 
esquema de diseño. 


El Esquema Relacional de diseño constará de los siguientes apartados: 
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1) Tablas. ' 
Descripción de las Tablas, sus atributos y sus claves primarias. 


2) Condiciones de Integridad deducibles del diagrama. 
Descripción de condiciones de integridad deducibles de las cardinalida- 
des. Descripción de claves adicionales deducibles también de las cardina- 
lidades. 


Estas descripciones tienen como objetivo fundamental dejar documenta- 
dos con precisión el significado e interrelaciones de los datos. 


Además, algunas de estas condiciones de integridad se incorporarán a 
los programas de actualización o al sistema para forzar a que se cumplan, 
protegiendo así la coherencia de los datos. Es aconsejable hacerlo así 
para las condiciones de Integridad de Referencia al menos (Reglas de 
Inserción, Actualización y Borrado, con las opciones de Rechazo, Propa- 
gación o Anulación, que se comentaron en el apartado «Modelo Relacio- 
nal de Datos»). Para otras condiciones menos importantes puede ser más 
conveniente no forzar su cumplimiento, pues podría introducir demasiada 
rigidez en el sistema. La experiencia y buen juicio del diseñador decidirán 
en cada caso. Así, por ejemplo, en el último apartado de este capítulo 
(B. de D. Universitaria) hay una condición que dice que todo alumno 
debe pertenecer al menos a un grupo. Esto obliga a asignar un grupo a 
cada alumno en el momento en que éste se matricule, lo que puede ser 
administrativamente complicado. Es preferible permitir temporalmente, 
hasta el comienzo del curso, la existencia de alumnos matriculados sin 
asignar a ningún grupo. 


3) Condiciones adicionales no deducibles del diagrama. 
Descripción de condiciones de integridad y claves adicionales no deduci- 
bles del diagrama. A lo largo de este capítulo veremos varios ejemplos. 


Las observaciones sobre el objetivo y uso de las condiciones de integridad 
que haciamos en el párrafo anterior son también válidas aqui. 


NORMALIZACION DEL DISEÑO 


En la mayor parte de los casos la obtención del diagrama RE/R nos 
conducirá de forma directa a un diseño normalizado FNBC. Puede haber casos, 
sin embargo, en que para poder expresar todas las Dependencias Funcionales 
existentes haya que distorsionar la forma espontánea de obtener el diagrama, 
con lo cual también se podría llegar probablemente a un diseño normalizado, 
pero a costa de complicar el proceso introduciendo asociaciones o rectángulos 
un tanto artificiosos o de significado no evidente. Por ello, en principio es 
preferible no preocuparse de esto, dibujando el diagrama de la forma más directa 
y natural posible, y repasando al final el diseño producido para incluir en él las 
Dependencias no tenidas en cuenta, normalizándolo o añadiéndole condiciones 
de integridad adicionales. 
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Sean los conjuntos siguientes: 
Cl (DND): Conjunto de los DNI de los clientes de un Banco. 
C2 (CTA): Conjunto de los números de cuenta del Banco. 


C3 (TIT): Conjunto de números que indican el orden de un Titular dentro de 
una cuenta. 


C4 (FIR): Código que indica si un Titular de una cuenta puede firmar talones 
de ésta (puede tomar dos valores: “S” o “N”). 


R: Asociación entre los clientes y las cuentas de las que son titulares. 


Una cuenta puede tener varios titulares. Un cliente puede ser titular de varias 
cuentas. Dentro de una cuenta, los clientes que son sus titulares están numerados 
consecutivamente, siendo éste el número de orden de titular dentro de la cuenta. 


Tendremos el siguiente diagrama: 


R (DNI,CTA) 


S (-DNI,CTA—,TIT) 


T (-DNI,CTA—,FIR) 
CL ICTA (-DNI,CTA—,TIT,FIR) 


Como dentro de una cuenta no se repiten los números de orden de los Titulares. 
en esta relación deberá ser clave (CTA, TIT). Es decir, que se cumple que (CTA, 
TIT>DND y (CTA, TIT>FIR). Sin embargo, la única clave obtenida en el 
diagrama es (DNI, CTA). Para corregir esta situación añadimos la nueva clave 
al diseño, quedando éste: 


Relación: CLICTA (DNI, CTA, TIT, FIR). 
Claves: (DNI, CTA) y (CTA, TIT). 


Se transforma en: 
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Para que el diagrama de partida produzca ambas claves podríamos haberlo 


dibujado así: 


S (DNI,CTA, TIT) | 
T (-DNI,CTA—,FIR) 


En este diagrama, S tiene dos asociaciones implícitas de cardinalidad (1: 1), que 
definen las claves (DNI, CTA) y (CTA, TIT), con lo que se llega al final al mismo 
diseño normalizado que antes. 


MECANIZACION DEL PROCESO DE DISEÑO 


El proceso de obtención del diagrama RE/R final, una vez dibujado el inicial, 
es fácilmente programable. Es además aconsejable hacerlo así, pues proporciona 
varias ventajas sobre un proceso manual. Cuando el número de rectángulos y 
asociaciones es elevado, como suele ocurrir en los casos prácticos, la transforma- 
ción a mano del diagrama, haciendo y rehaciendo el dibujo varias veces, puede 
ser laboriosa y propensa a errores. 


El uso de herramientas automatizadas nos da otras ventajas adicionales: 


a) Obliga a una sistemática homogénea independientemente de la persona 
que realice el diseño. 


b) Facilita la obtención de informes para documentación. 


c) Facilita la comunicación entre las personas involucradas en el proceso 
(diseñador, dirección y usuarios) y entre las que lo van a utilizar (analistas, 
programadores y usuarios finales). 


d) Permite analizar fácilmente varias alternativas de diseño para evaluar la 
más conveniente. Por ejemplo, evaluar el impacto de futuros cambios en 
las estructuras de datos. 
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e) Facilita el trabajo más tedioso del proceso, liberando al diseñador para 
labores más creativas. 


A modo de ejemplo de la ayuda que un programa sencillo de este tipo puede 
ofrecer, se incluyen en los Apéndices los resultados obtenidos al aplicar un 
programa a uno de los ejemplos que se presentan a continuación en este capítulo. 


EJEMPLOS 


A continuación se exponen algunos casos prácticos de diseño, muy simplificados 
en cuanto al número de atributos para que destaquen los aspectos interesantes 
sin perdernos en detalles demasiado prolijos. 


En los diagramas representaremos las asociaciones implícitas sin nombre, como 
hemos venido haciendo hasta aquí. Tampoco en las explícitas, a veces, pondremos 
nombre para simplificar el dibujo del diagrama. En este caso indicaremos que se 
trata de una asociación explícita poniéndole el signo $z. Esto lo haremos normal- 
mente cuando un rectángulo sólo participe en una asociación de cardinalidad 
(m : 1), pues no merece la pena ponerle un nombre que va a desaparecer al aplicar 
la regla de Supresión de Rectángulos. 


Ejemplo 1. Base de Datos de Fábricas y Países: 
Conjuntos de valores de partida: 


C1 (NP): Conjunto de números identificadores de países. 
C2 (NF): Conjunto de números identificadores de fábricas. 
C3 (NA): Conjunto de números identificadores de artículos. 
C4 (DP): Conjunto de descripciones de países. 

CS (DF): Conjunto de descripciones de fábricas. 

C6 (DA): Conjunto de descripciones de artículos. 


C7 (PR): Conjunto de precios de coste de los artículos producidos por todas 
las fábricas. 


Asociaciones: 


R1: Fábrica reside en país. 
R2: Fábrica produce artículos. 
R3: Precio asociado a un artículo producido por una fábrica. 


Diagrama C/A: 


Método y ejemplos de diseño / 199 


6 


Condición adicional: 
Dentro de un país, un determinado artículo no puede ser producido más que 
en una fábrica. 


Esta condición no se ha representado en el diagrama. 


Transformemos todas las anteriores asociaciones en implícitas y representemos 
también el precio de coste (R3): 


R6 (-NA= 
,DA-) 


m 
R3 
c4 (DP) ] pto | C7 (PR) C6 (DA) 


C5 (DF) 


o] 
E 
27 
Pz 
—U 
| 
L_ o 
2 
5 
MZ 
— UU 
o] 
2N 
zz 
4 
Lo 
A | 


Transformemos la asociación R3 en implícita: 


m 


R2 (NF, | N R6 (-NA— 
NA) ,DA-) 


3 


A 


C4 (DP) 


C7 (PR) 


C5 (DF) 


200 / Método y ejemplos de diseño 


Agregando y suprimiendo rectángulos queda: 


F (-NF-,—DF-,NP) 


D (-NF,NA—,PR) 


Esquema de diseño: 


1) Tablas: 
Países: P(-NP-, -DP>). 
Fábricas: F(-NF-, —-DF-, NP). 
Artículos: A(-NA—, —DA>). 
Fábricas que producen Artículos y a qué coste: D(-NF, NA-, PR). 
Claves primarias: NP (en P), NF (en F), NA (en A). 
2) Condiciones deducibles del diagrama: 
F[NP]<P[NP]. 
D[NF] =F[NF]. 
D[NA]<A[NA)]. 
La segunda condición anterior es más fuerte que una de Integridad de 
Referencia. Las otras dos son condiciones de Integridad de Referencia. Sus 
claves ajenas son F.NP y D.NA respectivamente. 
3) Condición no expresada en el diagrama: 
En (Fx D), (NP, NA) es clave. 


Por tanto, si E=P(NF, NA, NP, PR) (FxD), se verifica en E que: 
NF>NP; (NA, NP)>NF; (NA, NP)>PR, y además las claves son (NP, 
NA) y (NF, NA). Por lo tanto, E no está normalizada FN3. 


Ejemplo 2. Otra vez la Base de Datos de Fábricas y Países 


Supongamos el mismo ejemplo anterior, pero con la hipótesis adicional de que las 
fábricas están identificadas por números dentro de cada país. Por ejemplo: 


Pais Fábricas que tiene 
1 ZE 
2 19992 
3 1,2, 3,4 


A 
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Tendremos entonces que la asociación Rl es ahora (m:n): 


R1 
C1 (NP) C2 (NF) 
m n 


El diagrama RE/R, con asociaciones implícitas será: 


n m n 
R1 (NP R2 (NP, 
NF) Pe NF,NA) 


R3 (-NP, C6 (DA) 


C4 (DP) 
NF,NA— PR) 


Agregando y suprimiendo rectángulos: 


D (-NP,NF,NA—,PR) 
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Este diagrama es como el del ejemplo 1, pero con la diferencia de que el 
identificador de la Entidad «Fábrica» se compone de NP (identificador de país) 
y NF (identificador de fábrica dentro de país). 


Como (NP, NA) debe ser una clave en D, el esquema será el siguiente: 


Esquema de diseño 


1) Tablas: 
P(=NP-, —-DP-). Clave primaria: NP. 
F(=NP, NF-, -DF-). Clave primaria: (NP, NP). 
A(ENA-, -DA-). Clave primaria: NA. 
D(NP, NA-, NF, PR). 


Obsérvese que en D no se cumple NF>NP, a diferencia de lo que ocurre 
en E en el ejemplo 1, donde sí se cumple. El presente diseño está normalizado. 


2) Condiciones: 
F[NP]<P[NP]; D[NP, NF]=F[NP, NF];, D[NA]<A[NA)]. 


Este diseño es mejor que el obtenido en el ejemplo 1. En general, es aconsejable 
que los identificadores de entidades dependientes sean compuestos (en nuestro 
ejemplo, el identificador de Fábrica). 


El correspondiente diseño en IMS sería: 


A (-NA-,DA) 


¡ (hijo (hijo 
| lógico) lógico) 


Ejemplo 3. Parte de la B. de D. de una Empresa Industrial 


Consideremos los conjuntos siguientes: 


C1 (ND): Identificadores de Departamentos. 
C2 (NE): Identificadores de Empleados. 
C3 (NY): Identificadores de Proyectos. 
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C4 (NS): Identificadores de Suministradores. 

CS (NP): Identificadores de Productos. 

C6 (DNI): DNIs de los Empleados. 

C7 (DND: DNIs de los cónyuges de los Empleados. 
C8 (DND): DNIs de los hijos de los Empleados. 


Asociaciones: 


R1: Empleado trabaja en Departamento. 
R2: Empleado casado con cónyuge. 

R3: Empleado es padre de hijos. 

R4: Empleado trabaja para Proyecto. 

R5: Empleado dirige Proyecto. 

R6: Proyecto necesita Producto. 

R7: Suministrador suministra Producto. 

R8: Suministrador suministra para Proyecto. 
R9: Producto se compone de Producto. 


Supongamos que R8 es consecuencia de R6 y R7. La eliminamos por tanto. 


Diagrama C/A inicial: 


C6 (DNI) C7 (DNI) 


Transformemos todas las asociaciones en implícitas. Obtenemos así el diagrama 
RE/R de partida: 
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R4 (NY R5 (NE, RO (NY, R7 (NS, 
NE) =-NY-) NP) 5 
n n n n 


Bl C2 (NE) C5 (NP) 
(NP. 1) (NP.2) 
n 
= ; R2 (-NE-, R3 (NE, R9 (NP.1,NP.2) 
= —DNI-) —DNI-) 


C6 (DNI) C7 (DNI) se C8 (DNI) 


Agregando y suprimiendo rectángulos: 


R1 (-NE-,-DNI.ES-, 
—DNI.R2-,ND) 


a 
y R3 (-DNI-, NE) | 


C5 (NP) 


(NP. 1) (NP.2) 


R9 (NP. 1,NP.2) 
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Esquema de diseño 
1) Tablas: 


Empleados: 
R1 (¿NE-, -DNI.PROPIO-, -DNI.CONYUGE-, ND). 
Clave primaria: NE. 

Hijos de Empleados con DNI: 
R3 [DNI.HIJO-, NE). 


Empleados que trabajan en Proyectos: 
R4 (NY, NB). 
Empleados que dirigen Proyectos: 
RS (ENY-, NB). 
Productos usados en Proyectos: 
R6 (NY, NP). 
Suministradores de Productos: 
R7 (NS, NP). 
Productos (NP.1) que se componen de otros (NP.2): 
R9 (NP.1, NP.2). 


Productos: 
C5 (NP). 
Condiciones adicionales expresadas en el diagrama: 
R4[NE] <R1[NE]. 
RS[NE] <RI1[NE)]. 
R3[NE] <R1[NE). 
R4[NY] <R5[NY]. 
R6[NY] <R5[NY]. 
R6[NP] <C5[NP]. 
R9[NP.1]< CS[NP]. 
R9[NP.2] < C5[NP] 
Todas ellas son de Integridad de Referencia. 


2 


— 


3 


— 


Condiciones no expresadas en el diagrama: 


El grafo que representa la estructura de Productos no puede tener bucles, 
pues una pieza que se compone de otras no puede ser a su vez componente 
de éstas. Esto es aplicable a R9. 


Ejemplo 4. B. de D. para Gestión de Tesorería: 
Un Banco desea poner consultable a disposición de sus clientes una Base de Datos 


con los saldos y movimientos de sus cuentas. Naturalmente, cada cliente sólo 
podrá consultar datos de unas cuentas predeterminadas, normalmente aquellas de 


las que sea titular. 
Conjuntos de valores a representar: 


AI(NOMBRE): Conjunto de nombres de los clientes del Banco. Dos clientes 
distintos pueden llamarse igual. 
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A2(TIPOCTA): Conjunto de valores que representan distintos tipos de cuen- 
tas. Por ejemplo: 1=Cuentas corrientes, 2=Libretas de ahorro, 3 =Imposi- 
ciones a plazo fijo, etc. 

CLIENTE(4CL): Conjunto de números identificadores de los clientes. Supo- 
nemos que el Banco ha asignado uno de estos identificadores a cada 
uno de sus clientes. 

CUENTA(4CTA): Conjunto de números de cuenta de los clientes. 


A3(A4TIT): Conjunto de los números de orden de los titulares dentro de las 
cuentas. Se supone que dentro de cada cuenta los titulares están numerados. 


A4(FECHA): Conjunto de las fechas en las que vamos a tener información. 

AS(SALDO): Conjunto de los saldos de las cuentas en cada fecha. 

A6(4 MOV): Conjunto de los números identificadores de los movimientos de 
ca Se supone que cada movimiento está numerado dentro de cada cuenta y 
echa. 

AT(TIPOMOV): Código de tipo de movimiento (ingresos o reintegros). 

AS(CANT): Conjunto de las cantidades en pesetas de los movimientos. 


Entre clientes y cuentas hay una asociación que llamaremos TITULAR que nos 
asocia cada cuenta con los clientes que son sus titulares. 


La asociación CTAFECHA nos asocia cada cuenta con una fecha, y la asociación 
MOVIMIENTOS nos asocia cada cuenta y fecha con sus movimientos. 


El diagrama RE/R de partida es el siguiente: 


A1 A2 
(NOMBRE) (TIPOCTA) 
8 8 
m m 


CLIENTE CUENTA 
(4 CL) (4 CTA) 


Ad 
(FECHA) 


E 


TITULAR CTAFECHA 
(+$CL, (CTA, 
+CTA) FECHA) 


IMIEN- 
OS 


MOVI 
7 


8 


A7 A8 
(TIPOMOV) (CANT) 
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Se obtiene el siguiente esquema. 
Esquema de diseño 


1) Tablas: 
CLIENTES (-4CL-, NOMBRE). 
CUENTAS (-4CTA-, TIPOCTA). 
TITULARES (-4CL, 4CTA-—, A4TIT). 
SALDOS (E-4CTA, FECHA-, SALDO). 
MOVIMIENTOS (-4CTA, FECHA, 4MOV-, TIPOMOV, CANT). 


2) Condiciones expresadas en el diagrama: 


Todo identificador de cliente en TITULARES debe existir en CLIENTES. 

Todo identificador de cuenta en TITULARES debe existir en CUEN- 
TAS, y viceversa. 

Todo identificador de cuenta en SALDOS debe existir en CUENTAS, 
y viceversa. 


Toda pareja de valores de (4 CTA, FECHA) en MOVIMIENTOS debe 
existir en SALDOS. 


3) Condición no expresada en el diagrama: 


En TITULARES, la pareja de atributos (4CTA, 4TIT) es una clave 
alternativa. 


Ejemplo 5. B. de D. de Relaciones entre Empresas 


Supongamos que una Empresa puede adueñarse total o parcialmente del capital 
de otra mediante la compra de acciones en Bolsa u operaciones de otro tipo, sin 
ninguna restricción. De este modo podría incluso darse el caso de que una 
empresa filial poseyera acciones de su empresa matriz. 


Deseamos almacenar las relaciones de participación de capital entre empresas en 
una Base de Datos, de manera que podamos contestar a la pregunta de, dadas 
dos empresas A y B, qué parte del capital de una posee la otra, si es que posee 
alguna. 

Antes de entrar a analizar los datos, vamos a definir algo más el problema. 
Representemos en un grafo la relación entre empresas. Para ello cada empresa la 
representamos con un nodo del grafo, y la participación de capital de una en 
otra la representaremos mediante un arco dirigido sobre el que se indicará qué 
parte del capital de una es poseído por la otra. Así, por ejemplo: 


Mr PR 


Este gráfico indica que el 20% del capital de A pertenece a B. 


Evidentemente, en estos grafos puede haber bucles. Además, entre dos nodos no 
puede haber más de un arco en el mismo sentido, y la suma de los valores de los 
arcos que salen de un nodo no puede ser mayor que 1. 


Tomemos ahora el grafo siguiente: 


a a pr 
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Vemos en él que B posee el 20% del capital de A, y C el 50% del de B. Esto 
significa que, indirectamente, C posee el 10% de A. Esto lo representaremos con 
esta notación: (A: C)=0,1. 


Veamos otro ejemplo: 


Si en este grafo todo el capital de A está en manos de B y D, deberá ser (a+c)=1. 
La participación de C en A será: (A: C)=(a : b). 


En general, para hallar qué parte del capital de una empresa está en manos de 
otra hay que recorrer todos los caminos entre los nodos que las representan y 
sumar los productos de los arcos de cada camino. Veamos otro ejemplo: 


Hay tres caminos de A a F: 

(AB, BE, EF): adf. 

(AC, CE, EF): bef. 

(AD, DF): cg. 
Por tanto, la parte de A que es de F será: 

(A:F)=(adf+bef+cg). 
Evidentemente, si en el grafo anterior se ha representado todo el capital de A, B, 
C, D y E, la empresa A pertenece totalmente a F. En efecto, en este caso 
tendremos que: 

a+b+c=1. 

d=1. 

e=1. 

g=1. 

f=1. 
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Por tanto: 
(A: F)=(adf+bef+cg)=1 
Veamos ahora un ejemplo con bucle: 


a 
d 


Queremos hallar qué parte de B corresponde a C. Tenemos que recorrer todos 
los caminos posibles: 

(BC): d. 

(BA, AB, BC): cad. 

(BA, AB, BA, AB, BC): cacad. 

(BA, AB, BA, AB, BA, AB, BC): cacacad. 


La suma de todos ellos: 
(B:C)=d(1 +(ca)+(ca)?+(ca)?+---). 


1 
(B:C)=d— 
l—ca 
4 el grafo anterior representa todo el capital de A y B, sus únicos dueños serán 
yD 
En efecto, en este caso: 
a+b=1 
c+d=1 
Tendremos: 
(A: C)+(A : D)=ad(l +ac+(ac)?+--)+b(l+ac+(ac)?+--.)= 
ad 1 o 1 E ad+b PS a(l —c)+(1—a) -1 
l—ac l—=ac 1—ac l—ac 


Volvamos ahora a nuestro problema inicial. Nuestra Base de Datos deberá 
representar el grafo. Para ello tendrá que representar el conjunto de nodos 
(empresas) y el de arcos (es decir, participaciones directas). Cada arco es una 
asociación entre dos nodos. 
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Para hallar la participación de una empresa en otra construiremos un algoritmo 
que recorra todos los caminos entre sus nodos. Si no hay bucles será finito. Si 
hay bucles, tendrá infinitas iteraciones. Lo terminaremos cuando hayamos obteni- 
do una aproximación que estimemos suficiente. Es decir, cuando el resulta- 
do de la iteración (n+1) difiera en menos de una cantidad predeterminada del 


obtenido en la iteración (n). 
Conjuntos de valores que deseamos representar en nuestra Base de Datos: 


CI(NOMBRE): Conjunto de nombres de las Empresas. 

C2(TIPOEMP): Conjunto de códigos que indican tipo de empresa. 

C3(DOMICILIO): Conjunto de domicilios de las empresas. 

C4(CAPITAL): Conjunto de cantidades en pesetas que representan los capita- 
les de las empresas. 

EMPRESAS (4 EMP): Conjunto de números identificadores de las empresas. 


CS(P): Conjunto de cantidades que representan participaciones directas de 
capital de unas empresas en otras, en porcentajes. 


Los arcos del grafo los representaremos mediante la asociación: 
PARTICIPACIONES (4EMP.1, 4EMP.2) 


donde 4EMP.1 es el nodo origen del arco y 4EMP.2 el destino. 
El diagrama RE/R de partida es: 


C4 
(CAPITAL) 


E2 
(TIPOEMP) 


C1 C3 
(NOMBRE) (DOMICILIO) 


EMPRESAS 
(4e EMP) 


(4 EMP) (4 EMP) 


(44 EMP. 1) (++ EMP.2) 


PARTICIPACIONES 
(44 EMP. 1,4 EMP.2) 
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El esquema resultante es el siguiente: 


Esquema de diseño 


1) Tablas: 


EMPRESAS (-4EMP-, NOMBRE, TIPOEMP, DOMICILIO, CA- 
PITAL). 
PARTICIPACIONES (-4EMP.l, 4EMP.2-, P). 


2) Condiciones expresadas en el diagrama: 


Los valores de 4EMP.1 y 4EMP.2 en la tabla PARTICIPACIONES 
deben existir en la columna 4 EMP de la tabla EMPRESAS (Integridad 
de Referencia). 


3) Condiciones no expresadas en el diagrama: 


La suma de los valores de la columna P de todos los arcos que salen 
de un nodo no puede superar a 100. 


Con estas tablas podemos utilizar un algoritmo como el siguiente para hallar la 
participación de una empresa en otra. 


Algoritmo para hallar participaciones 


A) DATOS 
Tl y T2: Tablas relacionales para resultados intermedios. Inicialmente 
vacías. Tienen las mismas columnas que PARTICIPACIONES. 
NORI: Identificador de la empresa cuyo capital deseamos analizar para 
saber qué parte de él pertenece a otra. 
NDES: Identificador de esta última. 


RESU: Resultado buscado. Es decir, porcentaje del capital de NORI que 
pertenece a NDES. Inicialmente a ceros. 


INCR: Campo de trabajo. Almacena cuánto se incrementa R en cada 
nueva iteración. 


NITE: Número de iteraciones del algoritmo. Se utiliza para poner un límite 
al tiempo de ejecución. Inicialmente a ceros. 


NFTL: Campo de trabajo. Se utiliza para almacenar el número de filas de 
una tabla. 


B) PROCESO 
1) Extraer de PARTICIPACIONES todas las filas tales que 4EMP.]=- 
NORI y almacenarlas en Tl. 
2) Si Tl está vacía, fin del proceso. Si no, seguir. 
3) Sumar 1 a NITE. Si NITE=1000, fin del proceso. Si no, seguir. 
4) Borrar el contenido de T2, en caso de que no esté vacía. 
5) Almacenar el contenido de Tl en T2. 


6) Si no hay en T2 ninguna fila cuya columna 4EMP.2 sea igual a 
NDES, ir al paso (7). Si sí hay, hacer lo siguiente: 
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— Sumar la columna P de T2 para todas las filas que tengan 
4 EMP.2=NDES y almacenar el resultado en INCR. 


— Sumar INCR a RESU. 
— Continuar con el paso siguiente. 


7) Hallar la suma de los porcentajes, columna P de la tabla T2, para 
todas sus filas y almacenarla en INCR. 

8) Si INCR es menor que 0,1, fin del proceso. Si no, seguir. 

9) Borrar el contenido de T!l. 

10) Obtener la yunción de las tablas T2 y PARTICIPACIONES, con la 
condición de que 4EMP.2 de T2 sea igual a 4EMP.1 de PARTICI- 
PACIONES. Por cada fila de la yunción almacenar otra en Tl de 
manera que: 4EMP.l de Tl reciba el valor de 4EMP.1 de T2, 
AEMP-.2 de Tl reciba el valor de 4EMP.2 de PARTICIPACIONES. 
y P de Tl reciba el valor resultante de multiplicar P de T2 por P de 
PARTICIPACIONES. 


11) Volver al paso (2). 


Si hay en el grafo bucles con 100% en todos sus arcos, el proceso tendría un 
número infinito de iteraciones. Para evitar esto se ha utilizado un contador 
(NITE) del número de iteraciones con un límite predefinido. 


En el Apéndice se incluye un ejemplo de codificación del algoritmo anterior 
usando los lenguajes PL/I y SQL. 


Ejemplo 6. B. de D. para Reservas Ferroviarias 


Una Compañía de Ferrocarriles desea implantar un sistema de reservas de plazas 
para viajeros. El Departamento Comercial de la Compañía describe la estructura 
de información del transporte de viajeros mediante las definiciones y conceptos 
siguientes: 


Tren 


Un tren está formado por varios coches que se desplazan juntos, con origen y 
destino comunes y con las mismas paradas. 


Cada tren tiene un número identificador, único dentro de cada fecha. Es decir, 
en una fecha dada no puede haber dos trenes con el mismo identificador. 


Un identificador puede repetirse en distintas fechas, pero siempre corresponde a 
trenes con idénticas paradas y horario. Además, se pretende que el identificador 
del tren, conocido por los clientes a través de las Guías de Ferrocarriles, evoque 
una imagen de servicio determinada, por lo que para asignar el mismo identifica- 
dor a dos trenes en distintas fechas, además de tener iguales paradas y horario, 
deberán tener algunas características de servicio comunes definidas por la política 
Lt de la Compañía (por ejemplo, camas, restaurante, traslado de automó- 
viles, etc.). 


Composición de un tren 


Los coches que forman un tren no cambian durante su desplazamiento. Es decir, 
ni se le añaden ni se le quitan coches entre su origen y su destino. Si esto ocurriera, 
se considera que se forma un nuevo tren, con un nuevo identificador. 
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Lo mismo ocurriría si dos trenes que confluyen en una estación juntan sus coches 
a partir de ella. Se supone que se trata de un tren nuevo, con un identificador 
diferente. También puede darse el caso inverso: un tren que se divide en dos. Se 
supone que éstos son trenes distintos, con sus correspondientes identificadores 
diferentes. 


Dentro de un tren, cada coche está identificado por un número único. Además 
cada coche tiene un número identificador propio, independiente de los trenes en 
que se enganche, que lo identifica dentro del parque total de coches de la 
Compañía. 

Dos trenes con el mismo identificador, en fechas diferentes, pueden tener distintas 
composiciones. Por ejemplo, uno puede tener más coches que otro, en función de 
la demanda de plazas. 


Tipos de coches 


Cada tipo o modelo de coche tiene un número determinado de plazas de distintas 
características (camas, literas, primera clase, segunda, etc.). Vamos a simplificar 
suponiendo que este número es fijo (no siempre es así pues hay coches en los que 
algunas plazas pueden transformarse de una clase a otra). 


Cada plaza de un determinado tipo de coche tiene un número que la identifica 
dentro del coche. 


Tramo 


Es el recorrido entre dos paradas sucesivas de un tren. 


Se identifica con un número único dentro del recorrido correspondiente a un 
identificador de tren. 


Rutas 


La Compañía desea establecer un servicio de información a clientes que permita 
a éstos preguntar por los itinerarios más convenientes para ir de un origen a un 
destino dados. Esto permite además ofrecer rutas alternativas en caso de que en 
alguna no haya plazas. 


La consulta de Rutas, como la Reserva de Plazas, desea hacerse en tiempo real, 
lo que puede dar lugar a tiempos de respuesta muy lentos, por el gran número 
de combinaciones de trenes, estaciones y horarios que pueden presentarse. Por 
ello se decide hacer un programa que, tratando en diferido, no en tiempo real, 
todos los trenes y horarios, analice todos los trayectos posibles de todas las 
estaciones con todas, y elija los mejores. El criterio de optimización puede ser 
minimizar el número de transbordos o la duración del viaje. Una vez elegidos los 
trayectos óptimos para todas las parejas de estaciones (origen-destino) posibles, 
se almacenan en una tabla que llamaremos Tabla de Rutas, que se utiliza para 
responder a la consulta en tiempo real. 


Veamos un ejemplo de consulta de Rutas. Para fijar ideas, supongamos que la 
Tabla de Rutas contiene información sobre la red española de ferrocarriles, y que 
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CACERES 
a AC 
MERIDA 
LO) 
CARTAGENA 


un cliente deseara saber qué rutas hay para ir de Zafra a Cartagena (véase figura 
superior). Para responder a esta consulta hay que extraer las filas de la Tabla de 
Rutas que tienen origen y destino en estas estaciones. Podrían ser las siguientes: 


o 


Trayecto Salida Llegada 

Origen Destino Número  ———————— Número. —————— 

ruta ruta ruta De A tren Hora Día Hora Día 
Zafra Cartagena 1 Zafra Mérida  A2320 20.25 D 21.18 D 
Zafra Cartagena 1 Mérida Madrid  TR593 07.45 D+1 13.47 D+1 
Zafra Cartagena 1 Madrid Cartagena T124 15.45 D+1 21.28 D+1 
Zafra Cartagena Z Zafra Cáceres  A2320 20.25 D 22.30 D 
Zafra Cartagena 2 Cáceres Madrid F331 03.32 D+1 08.25 D+1 
Zafra Cartagena 2 Madrid Cartagena R520 08.45 D+1 15:33 D+1 


En este ejemplo se ofrecen dos rutas. Con la Ruta 2 se llega antes que con la 
Ruta 1, pero hay que hacer noche en el tren y esperar varias horas de madrugada 
en Cáceres. El cliente podrá elegir la que le convenga más. 


Esta tabla puede ser demasiado grande para tenerla en memoria. Para una red 
ferroviaria de 2.000 estaciones, al combinar todas con todas resultan 4.000.000 de 
posibilidades. Suponiendo una media de tres rutas por cada una y tres trayectos 
por ruta, tendríamos unos 36.000.000 de entradas en la tabla. Si cada entrada 
necesitara 50 octetos, la tabla ocuparía unos 1,8 Gigaoctetos. Esto nos lleva a 
almacenar la tabla en disco, como una tabla relacional cuyo esquema es: 


RUTAS (-ORIGEN.RUTA, DESTINO.RUTA, NUM.RUTA, NUM.TRA- 
YECTO-, ORIGEN.TRAYECTO, NUM.TREN, HORA.SALIDA, FECHA. 
SALIDA, HORA.LLEGADA, FECHA.LLEGADA). 
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Suponemos que, para una pareja de estaciones dada, las rutas se numeran 
consecutivamente de 1 en adelante (atributo NUM.RUTA de la tabla). El 
(NUM.TRAYECTO) se asigna dentro de cada ruta. 


En conclusión, los conjuntos de valores que deseamos representar en nuestra Base 
de Datos son los siguientes: 


Cl (TIPO_TREN): Conjunto de códigos que indican tipo de tren. 

C2 (NOMBRE): Conjunto de los nombres de trenes. 

TRENES (4 TREN): Conjunto de los identificadores de trenes. 

C3 (NOMBRE): Conjunto de los nombres de estaciones. 

ESTACIONES (4 ESTACION): Conjunto de los identificadores de estaciones. 

C4 (HORA_SALIDA): Conjunto de las horas en que salen los trenes de las 
estaciones en que paran. 

C5 (HORA_LLEGADA): Conjunto de las horas en que llegan los trenes a las 
estaciones en que paran. 

CA (4TRAMO): Conjunto de los identificadores de tramos. 

C7 (NOMBRE): Conjunto de los nombres de los viajeros. Cada vez que se 
reserva una plaza, se asigna al viajero un número identificador, que 
representaremos por xk VIAJERO, y se guardan su nombre, domicilio y 
teléfono para poder avisarle en caso de cambios de fuerza mayor que 
afecten a su reserva. 


COCHES (4COCHE): Conjunto de los identificadores de coches. 

C8 (TIPO_COCHE): Conjunto de códigos que indican el tipo de coche. 

C9 (4COCHE_EN_TREN): Conjunto de números que significan número de 
coche dentro de los trenes. 

C10 (FECHA): Conjunto de fechas. 

C11 (TELEFONO): Conjunto de los números de teléfono de los viajeros que 
tienen plaza reservada. 

Si un viajero no tiene teléfono, o no lo conocemos, le asignaremos el 
número 0. 

C12 (DOMICILIO): Domicilios de los viajeros que tienen plaza reservada. 

Cl3 di Conjunto de los identificadores de plazas dentro de los 
coches. 

C14 (TIPO_PLAZA): Conjunto de códigos que indican las características de 
las o de los coches (cama, litera, primera o segunda clase, fumador o 
no, etc.). 

C15 (A4VIAJERO): Conjunto de los identificadores asignados a los viajeros. 

TRAMOS (+4TREN, TRAMO): Conjunto de parejas de valores que asocian 
cada tren con sus tramos. 

RUTAS (-4ESTACION.1, AESTACION.2, ARUTA, ÁTRAYECTO-, 
ESTACION 3, 4TREN, HORA_SALIDA, FECHA_SALIDA, HORA _ 
LLEGADA): Tabla de Rutas para consultas en tiempo real. 


Significado de los atributos: 
(A4ESTACION.1): Estación origen de la ruta. 
(AESTACION.2): Estación de destino de la ruta. 


(ARUTA): Número identificador de la Ruta dentro de cada pareja de 
estaciones (origen-destino). 


(ATRAYECTO): Número de trayecto dentro de la ruta. 
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(4ESTACION.3): Estación origen del trayecto. 
(4TREN): Identificador del tren. 

PLAZAS_COCHE (TIPO_COCHE, APLAZA): Contiene las plazas de cada 
tipo de coche. 

COMPOSICION (4+TREN, FECHA, 4COCHE): Contiene la composición 
de cada tren. 

Significa que el coche 4COCHE forma parte del tren 4TREN que sale 
en el día FECHA. 

ENGANCHES (4TREN.1, FECHA.l, 4COCHE, 4TREN.2, FECHA.2): 
Nos indica qué coches pasan de un tren a otro, con los viajeros a bordo. 
Significa que si un viajero tiene plaza reservada en el coche 4COCHE 
para el tren 4TREN.!] que sale en el día FECHA.1, no necesita transbor- 
dar para cambiar al tren 4TREN.2 que sale en el día FECHA.2. 

PLAZAS _ OCUPADAS (4TREN, FECHA, 4COCHE, A»xPLAZA, 4TRA- 
MO): Nos indica qué plazas están reservadas y en qué tramos. 


Entre ESTACIONES y TRAMOS hay una asociación explicita que indica qué 
estación es origen de cada tramo. La llamamos «DE». 


Hay otra asociación explícita que indica qué estación es destino en cada tramo. 
La llamamos «A». 


Los conjuntos anteriores se representan en un diagrama RE/R inicial como el 
mostrado en la figura siguiente. 
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El esquema de diseño obtenido es el siguiente: 


Esquema de diseño 


1) Tablas: 
TRENES (-4TREN-, -NOMBRE-, TIPO_TREN). Clave primaria: 
TREN. 
ESTACIONES (4 ESTACION, NOMBRE-). Clave primaria: 4 ES- 
TACION. 


TRAMOS (E4TREN, 4TRAMO-, DE, A, HORA_SAL, HORA_ 
LLEG). 


COCHES (-4COCHE-, TIPO_COCHEB). 
PLAZAS_COCHE (TIPO_COCHE, 4PLAZA-, TIPO_PLAZA). 


COMPOSICION (-4TREN, FECHA, 4COCHE-, 4COCHE_EN_ 
TREN). 


ENGANCHES (-4TREN.1, FECHA.1, 4COCHE-, 4TREN.2, FE- 
CHA.2). 


PLAZAS OCUPADAS (-4TREN, FECHA, 4COCHE, xPLAZA, 
ÁATRAMO-, AVIAJERO). 


VIAJEROS (-4 VIAJERO—, NOMBRE, TELEFONO, DOMICILIO). 


RUTAS (-HA4ESTACION.1, 4ESTACION.2, ARUTA, 4TRAYEC- 
TO-, AESTACION.3, 4TREN, HORA_SALIDA, FECHA_SA- 
LIDA, HORA_LLEGADA, FECHA_LLEGADA). 


2) Condiciones adicionales expresadas en el diagrama: 


Clave alternativa en ENGANCHES: (4 COCHE, 4TREN.2, FECHA.2). 

Los valores de 4+TREN en TRAMOS tienen que existir en TRENES, 
y viceversa. 

Los valores de DE y A en TRAMOS tienen que existir en 4ESTA- 
CION de ESTACIONES. 

Los valores de TIPO_COCHE en PLAZAS_COCHE tienen que existir 


en COCHES. 

Los valores de 4+TREN en COMPOSICION tienen que existir en 
TRENES. 

Los valores de 4COCHE en COMPOSICION tienen que existir en 
COCHES 


Los valores de (4TREN.1, FECHA.1, 4COCHE) de ENGANCHES 
tienen que existir en COMPOSICION. 


Idem los valores de (4TREN.2, FECHA.2, 4COCHE). 


Los valores de (4 TREN, FECHA, 4COCHE) en PLAZAS OCUPA- 
DAS tienen que existir en COMPOSICION. 


Los valores de (4 PLAZA) en PLAZAS OCUPADAS tienen que existir 
en PLAZAS COCHE. 


Los valores de (4 VIAJERO) en PLAZAS OCUPADAS tienen que 
existir en VIAJEROS, y viceversa. 


Los viajeros de (4 ESTACION.1), (4ESTACION.2) y (AESTA- 
CION.3) en RUTAS tienen que existir en ESTACIONES. 


Los valores de (4 TREN) en RUTAS tienen que existir en TRENES. 
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3) Condiciones adicionales no expresadas en el diagrama: 

Claves alternativas en TRAMOS: (4TREN, DE), (4TREN, HORA _ 
SAL), (4 TREN, HORA_LLEG). 

Clave alternativa en COMPOSICION: (4TREN, FECHA, 4COCHE_ 
EN_TREN). 

Claves alternativas en RUTAS: (4ESTACION.1, 4AESTACION.2, 
ÁRUTA, 4ESTACION.3), (4ESTACION.1, 4ESTACION.2, 
RUTA, ATREN). 

Los valores de (4 TREN, 4 TRAMO) en PLAZAS OCUPADAS tie- 
nen que existir en TRAMOS. 


Ejemplo 7. B. de Datos de Clientes de un Banco 
Los conjuntos de valores a almacenar en la Base de Datos son los siguientes: 


C1 (NOMBRE): Conjunto de nombres de los clientes. 

C2 (DOMICILIO): Conjunto de domicilios de los clientes. 

C3 (FECHA_NAC): Conjunto de las fechas de nacimiento de los clientes. 

C4 (TIPO_CLIENTE): Códigos de tipos de clientes. 

C5 (PROFESION): Códigos de profesiones. 

C6 (SEXO): Códigos de sexo. 

CLIENTES (4CL): Conjunto de los identificadores de los clientes. 

REL_CLIENTES (4CL.1, 4CL.2): Conjunto de parejas de identificadores 
de clientes que están relacionados por algún criterio (por ejemplo, por ser 
familiares, por ser socios, etc.). 

EN dde Códigos de los tipos de relación que puede haber entre dos 
clientes. 

GRUPOS (4 GRUPO): Conjunto de los identificadores de grupos de clientes. 
Algunos clientes forman unidades con otros, a efectos de ciertas operacio- 
nes con el Banco. Estas unidades las llamamos grupos. Un grupo puede 
estar formado por varios clientes. Un cliente sólo puede pertenecer a un 
grupo. Ejemplo: un grupo de empresas (matriz y filiales) cuyas operaciones 
de riesgo con el Banco se negocian globalmente. 


Si un cliente no pertenece a ningún grupo, le asignaremos el grupo 0. 


C11 (DESGRU): Conjunto de descripciones o nombres de los grupos. 

PRODUCTOS (4PR): Conjunto de identificadores de todos los productos y 
servicios ofrecidos por el Banco. 

C10 (TIPO_PROD): Códigos de tipos de productos (por ejemplo, cuenta 
corriente, libreta de ahorros, imposición a plazo fijo, tarjeta de débito, etc. 

REL_PRODTS (+4PR.1, 4PR.2): Conjunto de parejas de identificadores de 
productos que están relacionados por algún criterio (por ejemplo, una 
cuenta de crédito con la cuenta corriente de donde se cobran los intereses). 

C8 (TIPO_REL): Códigos de los tipos de relación que puede haber entre los 
productos. 
TITULARES (4CL, 4PR): Asociación que indica qué clientes son titula- 
res de qué productos. 

C9 (4TIT): Conjunto de los números de orden de los titulares dentro de cada 
producto. 
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Los conjuntos anteriores se representan en un diagrama RE/R inicial como el 
mostrado en la figura siguiente. 
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El esquema de diseño obtenido es el siguiente: 


Esquema de diseño 
1) Tablas: 

CLIENTES (-4CL-, NOMBRE, DOMICILIO, FECHA_NAC, TIPO_ 
CLIENTE, PROFESION, SEXO, 4GRUPO). 

GRUPOS (-4GRUPO-, -DESGRU-). Clave primaria: 4GRUPO. 

REL_CLIENTES (-4CL.1, 4CL.2-, TIPO_REL). 

PRODUCTOS (-4PR-, TIPO_PROD). 

REL_PRODTS (-4PR.1l, 4PR.2-, TIPO_REL). 

TITULARES (HCL, 4PR-, 4TIT). 
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2) Condiciones adicionales expresadas en el diagrama: 

Los valores de 4GRUPO en CLIENTES tienen que existir en GRU- 
POS, y viceversa. 

Los valores de (CL. y (4CL.2) en REL_CLIENTES tienen que 
existir en CLIENTES 

Los valores de (4PR.1) y 4 PR.2) en REL_PRODTS tienen que existir 
en PRODUCTOS. 

Los valores de 4CL en TITULARES tienen que existir en CLIENTES. 

Los valores de 4PR en TITULARES tienen que existir en PRODUC- 
TOS, y viceversa. 


3) Condiciones adicionales no expresadas en el diagrama: 
Clave alternativa en TITULARES: (APR, 4TIT). 


Ejemplo 8. B. de D. Universitaria 


Un centro que ofrece clases de nivel universitario funciona con las siguientes 
normas. 
e Los alumnos se matriculan en las asignaturas que desean, siempre que 


respeten los prerrequisitos entre éstas. Así, por ejemplo, antes de poder 
cursar la asignatura Matemáticas-2 hay que haber aprobado Matemáticas-1. 


e Las clases admiten un máximo de 35 alumnos. Por ello, los alumnos 


matriculados en una asignatura se dividen en grupos, con un máximo de 35 
alumnos por grupo. 


e Los alumnos de un grupo asisten a las mismas clases, con el mismo horario. 


e Todos los grupos de una asignatura siguen el mismo programa, con los 
mismos textos y examenes. 


e Cada grupo sólo recibe una clase al día por asignatura. 


e Las clases de un grupo de una asignatura las da un solo profesor. Otros 
grupos de la misma asignatura pueden tener profesores diferentes. 


e A cada alumno se le asigna un profesor como tutor personal. 


e Los alumnos son calificados en todos los exámenes de las asignaturas en 
que están matriculados (la calificación es de 0 a 10, o «no presentado»). 
Deseamos diseñar una Base de Datos que contenga los conjuntos de valores 
siguientes: 
C1 (NOMBRE): Conjunto de nombres de las asignaturas. 
CS (LIBRO): Conjunto de títulos de todos los libros de texto que se usan en 
el Centro. 
C4 (4 ASIG): Conjunto de identificadores de asignaturas. 
PREREO (4ASIG.1, 4ASIG.2): Asociación entre asignaturas. Significa que 
la asignatura 4 ASIG.1 es prerrequisito para matricularse en la 4 ASIG.2. 
C3 (4GRUP): Conjunto de números de grupo. Á cada grupo se le asigna un 
número que lo identifica dentro de cada asignatura. 
GRUPOS (+4 ASIG, 4 GRUP): Asociación entre cada asignatura y sus grupos 
correspondientes. 
C6 (DIA): Conjunto de los nombres de los días de la semana. 
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C7 (HORA): Conjunto de las horas de comienzo de las clases. 

C8 (AULA): Conjunto de los identificadores de aulas. 

CLASES (4ASIG, 4GRUP, DIA): Días de clase por semana de cada grupo. 
C9 (4 ALUM): Conjunto de los identificadores de alumnos. 

C10 (4PROF): Conjunto de identificadores de los profesores. 

C11 (NOMBRE): Conjunto de nombres de los profesores. 

C12 (SUELDO): Conjunto de los sueldos de los profesores. 


C13 (CATEG): Conjunto de códigos que representan categorías o niveles de 
profesores. 


C15 (NOMBRE): Conjunto de nombres de los alumnos. 


C16 (AÑO): Conjunto de números que representan los años que cada alumno 
lleva estudiando en el Centro. 


C2 (A4EXAM): Cada asignatura tiene sus propios planes de exámenes. Los 
exámenes se identifican con un número dentro de cada asignatura. C2 es el 
conjunto de estos números. 


CALIFICACS (4ASIG, 4EXAM, 4+ALUM): Asocia cada alumno con los 
exámenes que le corresponden. 


C14 (NOTA): Conjunto de las notas obtenidas por los alumnos en los 
exámenes. 
Además tenemos las siguientes asociaciones explícitas: 

ENSEÑA: Asociación entre C10 y GRUPOS. Asocia cada profesor con las 
asignaturas y grupos donde dé clase. 


TUTOR: Asociación entre C10 y C9. Asocia cada profesor con los alumnos 
de que es tutor. 

MATRICS: Asociación entre C9 y GRUPOS. Asocia cada alumno con los 
grupos en que está mactriculado. 


El diagrama RE/R de partida es el siguiente: 
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Se obtiene el siguiente esquema de diseño. 


Esquema de diseño 


1) Tablas: 


ASIGNATURAS (-4ASIG-, -NOMBRE-). Clave primaria: 4ASIG. 
TEXTOS (4ASIG, LIBRO). 

PRERREOQO (4ASIG. 1, 4ASIG. 2). 

GRUPOS (-A4ASIG, 4GRUP-, 4PROPFP). 

El 4PROF representa al profesor que da las clases en cada grupo. 
CLASES (-A4ASIG, AGRUP, DIA—, HORA, AULA). 
ALUMNOS (-4ALUM-, NOMBRE, AÑO, 4PROF). 

El 4PROF representa al profesor que es tutor de cada alumno. 
MATRICS (4ASIG, 4GRUP, 4ALUM). 

PROFESORES (-4PROF-, NOMBRE, CATEG, SUELDO). 
CALIFICACS -AASIG, AEXAM, 4ALUM-, NOTA). 


2) Condiciones expresadas en el diagrama: 

Los valores de 4 ASIG en TEXTOS tienen que existir en ASIGNATU- 
RAS, y viceversa. 

Los valores de (4 ASIG. 1) y (4ASIG.2) en PRERREQ tienen que 
existir en ASIGNATURAS. 

Los valores de (4 ASIG) en GRUPOS tienen que existir en ASIGNA- 
TURAS. 

Los valores de (4 PROF) en GRUPOS tienen que existir en PROFE- 
SORES. 


Los valores de (4ASIG, 4GRUP) en CLASES tienen que existir en 
GRUPOS, y viceversa. 

Los valores de (4PROF) en ALUMNOS tienen que existir en PRO- 
FESORES. 

Los valores de (4ASIG, 4GRUP) en MATRICS tienen que existir en 
GRUPOS. 

Los valores de (4 ALUM) en MATRICS tienen que existir en ALUM- 
NOS, y viceversa. 

Los valores de (4 ASIG) en CALIFICACS tienen que existir en ASIG- 
NATURAS, y viceversa. 

Los valores de (4ALUM) en CALIFICACS tienen que existir en 
ALUMNOS, y viceversa. 


3) Condiciones no expresadas en el diagrama: 


Los valores de (4 ASIG, 4 ALUM) en CALIFICACS tienen que existir 
en MATRICS, y viceversa. 


Los prerrequisitos entre asignaturas no pueden tener «bucles». Es decir, 
una asignatura no puede ser prerrequisito de sí misma, directa o 
indirectamente. Esto se aplica a la tabla PRERREQ. 
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EJERCICIOS PROPUESTOS 


En los ejercicios siguientes, para simplificación de los dibujos, dejaremos a veces las 
asociaciones explicitas sin nombre. En este caso indicaremos que son explícitas adjuntan- 
doles el signo $. También, por la misma razón, se omitirán a veces los nombres de los 
conjuntos de valores representados en los rectángulos. 


1) Sean los conjuntos de valores siguientes: 


Cl (NE): Nombres de los empleados de una empresa. 

C2 (4D): Números identificadores de los departamentos de la empresa. 

C3 (ND): Nombres de los departamentos de la empresa. 

C4 (4T): Números de teléfono, dentro de la empresa, asignados a empleados. 


C5 (CJ): Código de si un empleado es jefe o no. Es un conjunto de dos valores: S (si 
es jefe), N (si no es jefe). 


Todos los empleados tienen nombres diferentes. 


Un departamento puede tener varios empleados o ninguno. Un empleado tiene que 
estar en un departamento y no puede pertenecer a más de uno. 


Un departamento no puede tener más de un jefe, aunque puede estar sin jefe en algún 
momento. 


Cada empleado tiene un teléfono. Si es jefe, lo usa en exclusiva, si no, comparte su 
uso con otros empleados no jefes. 


Representar la descripción anterior en un diagrama y obtener el esquema de diseño. 


2) Sean los conjuntos de valores siguientes: 


C1 (4M): Matrículas de los coches de una empresa asignados a sus vendedores. 
C2 (MO): Modelos de estos coches. 

C3 (4 V): Identificadores de vendedores. 

C4 (NV): Nombres de vendedores. 


La empresa dispone de una flota de coches para sus vendedores. A cada vendedor se 
le asigna un coche, y cada coche sólo se asigna a un vendedor. Sea R (4M, 4V) la 
asociación entre vendedores y coches. 


Representar esta descripción en un diagrama y obtener el esquema de diseño. 


3) La Regla de Propagación de Claves, tal como se enunció en el capítulo correspondien- 
te, se aplica entre dos rectángulos ligados por una asociación explícita de cardinalidad 
(1:n). Demostrar que también puede aplicarse cuando la cardinalidad es (c:n) si 
permitimos que el atributo propagado tome valores nulos. 


4) Queremos diseñar una Base de Datos para almacenar información sobre los Departa- 
mentos, Empleados y Oficinas de una empresa. Sus identificadores respectivos son 
AD, AE y 40. Por cada Departamento se desea almacenar su presupuesto (lo 
designaremos por PD) en pesetas, y el número identificador del empleado que lo dirige. 
También se desea guardar por Departamento los identificadores de sus empleados, los 
de las oficinas que ocupa y los Proyectos de los que cada Departamento es responsable. 
Los proyectos tienen'un identificador llamado 4P. Para cada empleado se desea saber 
los proyectos a los que está asignado, la oficina donde está su puesto de trabajo, y por 
tanto donde recibe su correspondencia y su número de teléfono en dicha oficina. Cada 
proyecto tiene un presupuesto, llamado PP, en pesetas, no incluido en el del Departa- 
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mento responsable del proyecto. Cada oficina tiene una superficie en metros cuadrados 
que se desea almacenar también, con el nombre SO. Para cada empleado se desea 
guardar una información histórica de los aumentos salariales que ha tenido, indepen- 
dientemente de si han ido acompañados de ascenso o no. Por cada subida de sueldo 
se guardará la fecha en que se ha producido (la llamaremos FS), la categoría 
profesional del empleado en ese momento (CP) y el nuevo sueldo en pesetas (NS). 
También se desea saber para cada oficina sus números de teléfono (los números de 
teléfono los designaremos como 4T). Un Departamento puede tener varios emplea- 
dos, proyectos y oficinas, pero a cada uno de éstos sólo corresponde un Departamento. 
Un teléfono está en una oficina. Una oficina puede tener varios teléfonos. 


Obtener el esquema relacional de diseño de la Base de Datos de acuerdo con esta 
descripción, completándola si hace falta con las hipótesis adicionales que se crean 
razonables. 


Queremos diseñar una Base de Datos para almacenar información sobre nuestros 
Clientes y sus Pedidos, cuyos identificadores respectivos son 4C y +P. Los artículos 
comercializados por nuestra organización tienen un identificador llamado 4A. Algu- 
nos son fabricados en factorías propias, cuyo identificador es 4F, y otros hay que 
adquirirlos en proveedores externos. Cada cliente dispone de un crédito cuyo límite 
se llama LC, de un descuento llamado DC por compras masivas, y de un saldo, SC, 
cuyo importe varía conforme va pagando los pedidos entregados. Los pedidos se 
entregan en una dirección de entre varias posibles de cada cliente. Estas direcciones 
se llaman DE (dirección de entrega). Los pedidos se componen de dos partes: una 
cabecera de pedido y varias líneas de detalle. En la cabecera figuran la fecha del pedido 
y el cliente que lo hace. Las líneas de detalle contienen el artículo pedido y la cantidad 
pedida. Se desea guardar toda esta información en la Base de Datos. Cada artículo 
tiene una descripción única. Se desea también llevar un control de las necesidades 
de fabricación. Para ello, por cada fábrica propia se guardará el nivel de inventario 
en el almacén de la fábrica de cada artículo (CD: Cantidad Disponible), y el nivel 
mínimo de existencias a partir del cual hay riesgo de quedarse sin existencias (NR: 
Nivel de Riesgo). Un pedido puede servirse en varias entregas. Para llevar un control 
de éstas, se guardará por cada línea de detalle un contador con lo que queda pendiente 
de entregar en cada momento, que se llama PE. 


Obtener el esquema relacional de diseño de la Base de Datos de acuerdo con esta 
descripción, completándola si hace falta con las hipótesis adicionales que se crean 
razonables. 
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Recordatorio de la 
notación utilizada 


D: Conjunto de dominios. 

<: Operador entre conjuntos que signifi- 
ca «contenido en» o «igual a». 

(QD: Conjunto vacío. 

R: Conjunto de todas las relaciones posi- 
bles construidas sobre D. 

U: Unión de conjuntos. 

—: Diferencia de conjuntos. 

n: Intersección de conjuntos. 

P(A) (R): Proyección de la relación R 
sobre su atributo A (leer: Proyección 
sobre A de R). 

R[A]: Proyección de la relación R sobre 
su atributo A. 

S(F) (R): Selección según la fórmula F 
sobre la relación R. 

R(X=x, Y): Conjunto de todos los valo- 
res de Y que están en las tuplas que 
tengan X=x en la relación R. 

R/S: Cociente entre las relaciones R y S. 

<: Operación entre conjuntos. Significa 
«contenido en». 

C: Operador de comparación, en general. 

Y: Yunción de relaciones. 

R Y S(¡Cj): Yunción de las relaciones R y 
S con la condición C entre los atributos 
ide R yjdeS. 

RYS: Yunción natural entre las relacio- 
nes R y $. 

R *S: Yunción natural entre las relaciones 
R yS. 


APENDICE 


YP: Yunción posibilista («may-be-join»). 
YE: Yunción externa. 
UE: Unión externa. 


TUP: Conjunto de todas las tuplas posi- 
bles formadas con los dominios de D. 


DOM(t): Conjunto en el que toma valo- 
res una variable t. 

t(1): Primer componente de la tupla t. 

3: Cuantificador de existencia («existe un»). 

V: Cuantificador universal («para todo»). 

CINT: Conjunto de condiciones de inte- 
gridad. 

DF: Conjunto de Dependencias Funcio- 
nales. 

DF +: Clausura de DF. 

>: Dependencia Funcional. 

> Dependencia Plural (multivaluada). 

DEP: Conjunto de Dependencias Funcio- 
nales y Plurales. 

DEP+: Clausura de DEP. 

DY: Dependencia Yuncional («join de- 
pendency»). 

DG: Dependencia Generalizada. 

DG: Conjunto de Dependencias Genera- 
lizadas. 

A: Operación lógica «Y» (AND). 

v: Operación lógica «O» (OR). 

1 Operación lógica de negación (NOT). 
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Operadores lógicos 


Los representamos por a (operador «Y», o de conjunción), vw (operador 
«O», o de disyunción) y — (operador «NO», o de negación). 


Estos operadores se aplican a operandos que son variables o expresiones que 
pueden tomar uno de dos valores posibles: o el valor «V» (Verdadero) o el valor 
«EF» (Falso). El resultado de aplicar los operadores también puede tomar uno 
de estos dos valores. 


Los operadores a y v se aplican a dos operandos. El operador — se aplica 
a un solo operando. 


El resultado de » es «V» si los dos operandos a los que se aplica tienen el 
valor «V». En caso contrario, el resultado es «F». Esto se expresa en la siguiente 
tabla: 


YA E 
Via E 
FEF E 
El resultado de v es «V» si uno cualquiera de sus dos operandos, o ambos, 


tienen el valor «V». Esto se expresa en la siguiente tabla: 


YA Vi E 
WALEW Vi 
F|IV EF 
El resultado de — es «V» si su operando tiene el valor «F». En caso contrario, 
el resultado es «F». 
Ejemplos: 


Consideremos el conjunto de los empleados de una empresa. Sea E una variable 
que toma valores en el conjunto de edades de los empleados, y S otra variable 
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que toma valores en el conjunto de los sueldos de los empleados. Podemos 
construir las expresiones siguientes: 


e (E>30). 


Esta expresión tomará el valor «V» para todos los empleados de más de 30 
años y «F» para el resto. 


(S> 200). 

Esta expresión tomará el valor «V» para todos los empleados que ganen 
más de 200.000 pesetas. 

(E>30) n (S> 200). 


Tomará el valor «V» para todos los empleados que cumplan a la vez ambas 
condiciones. Es decir, para los que tengan más de 30 años y ganen más de 
200.000 pesetas. 


(E>30) v (S>200). 
Será «V» para todos los empleados que cumplan una cualquiera de las dos 
condiciones. Es decir, para todos los que, o bien tengan más de 30 años, O 
bien ganen más de 200.000 pesetas, o bien ambas cosas a la vez. 
— (E>30). 
Será «V» para todos los empleados en los que la condición (E> 30) sea 
«F». Es decir, para todos los que no tengan más de 30 años. 
((E> 30) a (S > 200)) v (S > 300). 


Será «V» para los empleados que o bien ganen más de 300.000 pesetas, o 
bien ganen más de 200.000 y tengan más de 30 años. 
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Programa para relaciones 
entre empresas 


PARTEM0O1 : PROC OPTIONS (MAIN) ; 


/* ESTE PROGRAMA CALCULA EL PORCENTAJE DEL CAPITAL DE */ 


pe UNA EMPRESA QUE PERTENECE A OTRA. EL IDENTI- a 
/* FICADOR DE LA PRIMERA SE LEE EN NORI, Y EL DE  */ 
FA LA SEGUNDA EN NDES. ie 


DCL NORI CHAR (4), 
NDES CHAR (4), 
RESU DECIMAL FIXED (6,2), 
INCR DECIMAL FIXED (6,2), 
NITE BIN FIXED, 
NFIL BIN FIXED ; 


EXEC SQL INCLUDE SQLCA ; 
EXEC SQL INCLUDE PARTICIPACIONES ; 
EXEC SQL WHENEVER SQLERROR GO TO MENERR ; 


EXEC SQL CREATE TABLE T1 
(NEM1 CHAR (4) NOT NULL WITH DEFAULT 
,NEM2 CHAR (4) NOT NULL WITH DEFAULT 
,»P DECIMAL (5, 2) NOT NULL WITH DEFAULT 
); 


EXEC SOL CREATE TABLE T2 
(NEM1 CHAR (4) NOT NULL WITH DEFAULT 
,NEM2 CHAR (4) NOT NULL WITH DEFAULT 
,P DECIMAL (5, 2) NOT NULL WITH DEFAULT 
e 


NITE = 0; 
RESU=0 5 
INCR = 100 


GET DATA (NORI, NDES) ; 
PUT DATA (NORI, NDES) ; 


EXEC SQL INSERT INTO T1 


SELECT * 
FROM PARTICIPACIONES 
WHERE NEM1 = : NORI ; 
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DO WHILE ( INCR > 0.05 ) ; 


EXEC SQL SELECT COUNT(*) 
INTO : NFIL 
FROM T1 ; 


IF NFIL = O THEN GO TO FIN; 
NITE = NITE + 1; 
IF NITE = 1000 THEN GO TO FIN; 


EXEC SQL DELETE FROM T2; 
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EXEC SQL INSERT INTO T2 
SELECT * 
FROM T1; 


EXEC SQL SELECT COUNT(*) 
INTO : NFIL 
FROM T2 
WHERE NEM2 = : NDES; 
IF NFIL > 0 THEN DO; 
EXEC SQL SELECT SUM(P) 
INTO : INCR 
FROM T2 
WHERE NEM2 = : NDES; 
RESU = RESU + INCR; 
END; 


EXEC SQL SELECT SUM (P) 
INTO : INCR 
FROM, T2 ¿ 


EXEC SQL DELETE FROM T1; 
EXEC SQL INSERT INTO T1 
SELECT X.NEM1, Y.NEM2, ((X.P) * (Y.P)) / 100 
FROM T2 X, PARTICIPACIONES Y 
WHERE X.NEM2 = Y.NEM1 ; 


END ; 


FIN : 
PUT LIST ('NUMERO ITERACIONES :') ; 
PUT DATA (NITE) ; 
PUT LIST ('RESULTADO :') ; 
PUT DATA (RESU) ; 
EXEC SQL DROP TABLE T1; 
EXEC SQL DROP TABLE T2; 
GO TO SALIR ; 


MENERR 
PUT LIST ('ERROR SENTENCIA SOL ') ; 
PUT DATA (SQLCODE) ; 
GO TO SALIR ; 


SALIR: 
END; 
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Programa para diseño 


DESCRIPCION GENERAL 


Ya hemos comentado previamente la conveniencia de automatizar el proceso 
de diseño. A modo de ejemplo incluimos aquí una breve descripción funcional 
de un programa que puede servir de ayuda en la aplicación de las reglas de 
transformación a un diagrama RE/R. También se incluye una somera descripción 
de la entrada y la salida- producida al aplicarlo a uno de los ejemplos del texto, 
con el propósito de que esta información pueda ser útil para los que deseen 
desarrollar su propia herramienta de diseño. 


El programa ha sido escrito en BASIC, y desarrollado y probado en un IBM 
PC XT de 256K. Se compone de varias fases. Se ejecuta cargando la primera 
de ellas (con LOAD) y ejecutándola (RUN). A partir de aquí el programa va 
invocando a las fases siguientes conforme se van necesitando. Durante la 
ejecución se envían mensajes a la pantalla para indicar por dónde va avanzando 
el proceso. También se pueden tomar puntos de rearranque (checkpoints) para 
no perder todo el proceso realizado en caso de interrupciones voluntarias (teclas 
CTRL-Break) o involuntarias (fallo de potencia). 


ENTRADA DE DATOS 


Hay que describirle al programa el diagrama RE/R de partida, proporcio- 
nándole los nombres de todos los rectángulos, atributos y asociaciones, así como 
las cardinalidades de éstas. 


Esta entrada de datos se hace a través de un diálogo conducido por el 
programa, respondiendo por pantalla a sus preguntas conforme las vaya hacien- 
do. En ciertos momentos de este diálogo, el programa da la oportunidad de 
modificar y corregir los datos introducidos, por si se han tecleado errores. 


El programa permite guardar en disco los datos de una sesión de trabajo, y 
completarlos o modificarlos en sesiones posteriores. Esto simplifica la entrada de 
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datos de diagramas complejos. También es útil para hacer simulaciones sobre 
cómo afectaría al diseño un cambio en una asociación, o en una cardinalidad, etc. 


También se puede descomponer un diagrama en otros más pequeños, y 
procesar éstos independientemente. Luego se pueden fundir en otro más grande, 
introduciendo además nuevas interrelaciones entre ellos. Esto permite descom- 
poner el diseño en varias etapas, o tener unos subdiagramas generales que 
formen parte de diversos diseños, evitando tener que teclear sus datos cada vez. 


En las páginas siguientes se incluye el diálogo de pantalla para la introduc- 
ción de la Base de Datos Universitaria cuyo diagrama RE/R se describió en el 
último ejemplo del capítulo anterior. 


SALIDA 


El diseño obtenido puede verse por pantalla, imprimirse o grabarse en disco. 
Esto último permitiría editarlo y modificarlo empleando un editor cualquiera del 
PC, o también enviarlo a un ordenador conectado al PC, donde podría ser 
utilizado para definir las tablas e índices si en este ordenador estuviera instalado 
el sistema relacional que vamos a usar. 


La salida producida tiene cinco apartados: 


a) Entidades. Listado de las entidades resultantes, indicando cuáles son 
fuertes, dependientes o de asociación. 


b) Tablas. Listado de las tablas, sus atributos y sus claves. 


c) Asociaciones implícitas. Listado de las asociaciones implícitas entre tablas, 
con sus cardinalidades. 


d) Condiciones de integridad. Listado de las condiciones que se deducen de las 
cardinalidades especificadas en el diagrama. 


e) Protodefiniciones SOL. Listado de las sentencias CREATE de SQL necesa- 
rias para definir las tablas y sus índices. Es útil si el sistema relacional 
que se usa emplea este lenguaje. Estas sentencias no incluyen las caracte- 
rísticas de los atributos (por ejemplo, CHAR, VARCHAR, DECIMAL, 
etcécera.), por lo que hay que completarlas antes de introducirlas en el 
sistema. Tampoco incluyen la especificación de qué clave se designa como 
primaria ni de las reglas de mantenimiento de la Integridad Referencial 
(Restricción, Propagación o Anulación). Estas decisiones dependen de 
consideraciones semánticas no recogidas en el programa, por lo que hay 
que especificarlas manualmente. 


Las sentencias de definición de índices se agrupan en dos tipos: 


e Las que definen los indices correspondientes a las claves de las 
tablas. 


e Las que definen índices que son convenientes para poder comprobar 
si se cumplen las condiciones de integridad de referencia deducidas 
del diagrama. 
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Cuando el programa aplica la regla de Agregación de Rectángulos, le asigna 
al rectángulo resultante un nombre que se compone concatenando los de los 
agregandos separados por un guión. Esto puede producir nombres arbitrarios 
poco significativos. Sin embargo, si el nombre de uno de los agregandos empieza 
por 82, su nombre no interviene en la formación del nombre resultante. Por ello, 
en caso de que los nombres obtenidos sean poco significativos conviene modificar 
los del diagrama introduciendo otros con é. Así, por ejemplo, al aplicar el 
programa a la B. de D. Universitaria definida más arriba, se obtienen los 
nombres de entidades siguientes: 


812 (Entidad: Textos). 

C1-C4 (Entidad: Asignaturas). 

C10 (Entidad: Profesores). 

C9-TUTOR (Entidad: Alumnos). 
CALIFICACS (Entidad: Calificaciones). 
GRUPOS-ENSEÑA (Entidad: Grupos). 
MATRICS (Entidad: Matrículas). 
PRERREO (Entidad: Prerrequisitos). 


Para obtener nombres más mnemotécnicos introducimos los cambios siguientes: 


Al rectángulo Cl le llamamos Cl. 

Al C4 le llamamos ASIGNATURAS. 

Al C10, PROFESORES. 

Al C9, ALUMNOS. 

A la asociación entre CS y C4 la llamamos TEXTOS. 
A la asociación TUTOR la llamamos £«¿TUTOR. 

A la asociación ENSEÑA la llamamos £¿ENSEÑA. 


En las páginas siguientes se incluye la salida producida después de introducir 
estos cambios de nombres. 


APLICACION A LA B. D. UNIVERSITARIA 


A continuación se incluye un listado del diálogo de pantalla para introducir 
los datos de la B. D. Universitaria del capítulo anterior. Este listado va seguido 
del diseño obtenido. 


LOAD"direl0 
Ok 


RUN 
AXAKÍARAAKRAARARK FASE Q *X*X*XXXAXXXAXXKXXKXXX 


XKKKKKKKKKKKKKX FASE q RXAKKAKKKKKKKKKKXK 
¿Desea que se repitan las respuestas numeradas dadas en - 
otra sesión? (S/N):n 
¿Desea crear un fichero de respuestas con las de - 
esta sesión? (S/N):n 
(9) ¿Desea arrancar en caliente (en el último checkpt)?: n 
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(1)¿Desea tracear datos? (S/N): n 

(2)¿Desea tomar puntos de rearranque (checkpoints)? (S/N): s 
(3)Nombre del fichero (si distinto del de por omisión): 
(16)¿Desea fundir dos diagramas en uno? (S/N) : n 
XARXA KARETN DE FASE 1 KAKKKKKKKKKKKKXKxx 


*xXX****Empieza FASE 2 (Entrada de datos)****x*x 
KXKXXXXXX*xTO ma de datos * XARXA 
(4)¿Desea tomar los datos a partir de un fichero de entrada?: n 
Título del diagrama:Base de Datos Universitaria 
*****Introducir datos de PECTANGULOS: 

Nombre de rectángulo (si no hay más dar intro):C1 
Nombre de atributo (si no hay más dar intro) :NOMBRE 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C2 
Nombre de atributo (si no hay más dar intro): $EXAM 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C3 
Nombre de atributo (si no hay más dar intro): ¿GRUP 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C4 
Nombre de atributo (si no hay más dar intro): $ASIG 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C5 
Nombre de atributo (si no hay más dar intro):LIBRO 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C6 
Nombre de atributo (si no hay más dar intro):DIA 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C7 
Nombre de atributo (si no hay más dar intro): HORA 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C8 
Nombre de atributo (si no hay más dar intro): AULA 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C9 
Nombre de atributo (si no hay más dar intro): $¿ALUM 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C10 
Nombre de atributo (si no hay más dar intro): PROF 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C11 
Nombre de atributo (si no hay más dar intro): NOMBRE 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C12 
Nombre de atributo (si no hay más dar intro): SUELDO 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C13 
Nombre de atributo (si no hay más dar intro):CATEG 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C14 
Nombre de atributo (si no hay más dar intro): NOTA 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C15 
Nombre de atributo (si no hay más dar intro): NOMBRE 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro):C16 
Nombre de atributo (si no hay más dar intro): AÑO 
Nombre de atributo (si no hay más dar intro): 

Nombre de rectángulo (si no hay más dar intro): PRERREO 
Nombre de atributo (si no hay más dar intro): $ASIG 
Nombre de atributo (si no hay más dar intro): $¿ASIG 

Atr. repetido en el rectángulo, Sufijo= 2 
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Nombre de atributo (si no hay más dar intro): 
Nombre de rectángulo (si no hay más dar intro): GRUPOS 
Nombre de atributo (si no hay más dar intro): +ASIG 
Nombre de atributo (si no hay más dar intro): +GRUP 
Nombre de atributo (si no hay más dar intro): 
Nombre de rectángulo (si no hay más dar intro): CLASES 
Nombre de atributo (si no hay más dar intro): $ASIG 
Nombre de atributo (si no hay más dar intro): +GRUP 
Nombre de atributo (si no hay más dar intro) :DIA 
Nombre de atributo (si no hay más dar intro): 
Nombre de rectángulo (si no hay más dar intro):CALIFICACS 
Nombre de atributo (si no hay más dar intro):$ASIG 
Nombre de atributo (si no hay más dar intro): +EXAM 
Nombre de atributo (si no hay más dar intro): +ALUM 
Nombre de atributo (si no hay más dar intro): 
Nombre de rectángulo (si no hay más dar intro): 
*x**x*x*Introducir datos de CLAVES: 
Nombre de rectángulo (o intro para acabar): 
***x**Introducir datos de ASOCIACIONES: 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación: £l 
Nombre de rectángulo ORIGEN:C1 
Nombre de rectángulo DESTINO: C4 
Cardinalidad origen:1 
Cardinalidad destino:1l 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación:£2 
Nombre de rectángulo ORIGEN:C5 
Nombre de rectángulo DESTINO:C4 
Cardinalidad origen:M 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación:£3 
Nombre de rectángulo ORIGEN:C7 
Nombre de rectángulo DESTINO: CLASES 
Cardinalidad origen:1l 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación:84 
Nombre de rectángulo ORIGEN:C8 
Nombre de rectángulo DESTINO: CLASES 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explicita (S/N):? S 
Nombre de la asociación:8£5 
Nombre de rectángulo ORIGEN:C11 
Nombre de rectángulo DESTINO: C10 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación: £6 
Nombre de rectángulo ORIGEN:C13 
Nombre de rectángulo DESTINO: C10 
Cardinalidad origen:l 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
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Es una asociación explícita (S/N):? S 
Nombre de la asociación:£7 
Nombre de rectángulo ORIGEN:C12 
Nombre de rectángulo DESTINO:C10 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación:£8 
Nombre de rectángulo ORIGEN:C16 
Nombre de rectángulo DESTINO:C9 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación: £9 
Nombre de rectángulo ORIGEN:C15 
Nombre de rectángulo DESTINO: C9 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación:£10 
Nombre de rectángulo ORIGEN:C14 
Nombre de rectángulo DESTINO:CALIFICACS 
Cardinalidad origen:1 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación: MATRICS 
Nombre de rectángulo ORIGEN: C9 
Nombre de rectángulo DESTINO: GRUPOS 
Cardinalidad origen:N 
Cardinalidad destino:M 
¿Desea definir una asociación (S / N) 
Es una asociación explícita (S/N) 
Nombre de la asociación:ENSEÑA 
Nombre de rectángulo ORIGEN:C10 
Nombre de rectángulo DESTINO: GRUPOS 
Cardinalidad origen:1 
Cardinalidad destino:N 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? S 
Nombre de la asociación: TUTOR 
Nombre de rectángulo ORIGEN:C10 
Nombre de rectángulo DESTINO:C9 
Cardinalidad origen:1 
Cardinalidad destino:N 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C4 
Nombre de rectángulo DESTINO: PRERREQ 
Cardinalidad origen:1 
Cardinalidad destino:N 
Nombre de atr. común (si no hay más, intro):f$ASIG 
Sufijo del atr. común en destino:1 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C4 
Nombre de rectángulo DESTINO: PRERREOQO 
Cardinalidad origen:1 


2:38 
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Cardinalidad destino:N 
Nombre de atr. común (si no hay más, intro): f$ASIG 
Sufijo del atr. común en destino:2 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C2 
Nombre de rectángulo DESTINO: CALIFICACS 
Cardinalidad origen:1 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro): +EXAM 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C4 
Nombre de rectángulo DESTINO: CALIFICACS 
Cardinalidad origen:1l 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro): $ASIG 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C4 
Nombre de rectángulo DESTINO: GRUPOS 
Cardinalidad origen:1 
Cardinalidad destino:N 
Nombre de atr. común (si no hay más, intro): $ASIG 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C3 
Nombre de rectángulo DESTINO: GRUPOS 
Cardinalidad origen:1 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro): *+GRUP 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C6 
Nombre de rectángulo DESTINO: CLASES 
Cardinalidad origen:1 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro):DIA 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:GRUPOS 
Nombre de rectángulo DESTINO: CLASES 
Cardinalidad origen:1l 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro): R$ASIG 
Nombre de atr. común (si no hay más, intro): +GRUP 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)?:S 
Es una asociación explícita (S/N):? N 
Nombre de rectángulo ORIGEN:C9 
Nombre de rectángulo DESTINO: CALIFICACS 
Cardinalidad origen:1l 
Cardinalidad destino:M 
Nombre de atr. común (si no hay más, intro): +ALUM 
Nombre de atr. común (si no hay más, intro): 
¿Desea definir una asociación (S / N)2:N 
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Cuando esté listo para seguir dé intro: 

¿Desea modificar algún dato (S/N)?:N 

¿desea volver a introducir (o modificar) más datos:?N 
(6)¿Desea salvar a disco los datos introducidos? (S/N): s 
(7)Nombre del fichero de salida (incl. camino): bduniv.dat 
Datos salvados 

¿Desea listar los datos introducidos? (S/N):n 

XK KRAKKKKAKKAKRETN DE FASE 2 RIAKKKKKKKKKKKKkKXk 
****Empieza FASE 3 (Validación de datos) ***x* 

Empieza clasificación de mclav por rect.-clave 

Fin de clasifcn. de mclav por rect. 

*X*X*X*XXEFIN DE VALIDACION DE DATOS **x*xx*x* 

¿Desea reintroducir, modificar o salvar datos (S/N):? N 
KXKAKKKKKKKKKAKXKETN DE FASE 3 KAKXKIKKKKKKKKKKAKk 

***x*x Empieza FASE A (Listar datos de entrada) ***x* 
(12)¿Desea listar los datos de partida? (S/N): n 
KKAKKKKKKKKKKkXxxk FIN DE FASE A KIKKKKKKKKKKXx 

**** Empieza FASE 4 (Definir claves) **** 

Empieza Definición de claves 

Fin de Definir Claves 

Empieza designación de claves primarias 

Fin de designación de claves primarias 

*X***X*EIN DE APLICACION DE REGLA DE DEFINIR CLAVES **x*x*x* 
KKAKKKKKKKKKKKKETN DE FASE 4 KKKKKKKKKKKKKKkKA 
***X*XXXXEMPIEZA FASE 5 (Pasar asoc. expl. a impl.) ****x*xxx 
transformar asocs. explícitas en impl. 

fin de transf. de asoc. expl. en impl. 

KAKKXKKKKKKKX FIN DE FASE 5 KAKKKKKKKKKKkkxk 


**x*x* Empieza FASE 6 (Aplicación de Reglas) **** 


(Iteración: d ) 

Empieza Definición de claves 

Nueva clave en rect.: £l 
Nueva clave en rect.: £3 
Nueva clave en rect.: £4 
Nueva clave en rect.: £5 
Nueva clave en rect.: £6 


(Cuando esté listo para seguir dé INTRO) 


Nueva clave en rect.: £7 
Nueva clave en rect.: £8 
Nueva clave en rect.: £9 
Nueva clave en rect.: £10 
Nueva clave en rect.: ENSEÑA 
Nueva clave en rect.: TUTOR 
Nueva clave en rect.: £1l 


Fin de Definir Claves 
Empieza designación de claves primarias 


En el rectángulo: £l ,»la clave 

número 2 ¿Pasa a ser primaria. 
En el rectángulo: £3 ,la clave 

número 2 ¿pasa a ser primaria. 
En el rectángulo: £4 ,la clave 

número 2 ¿pasa a ser primaria. 
En el rectángulo: ES ,la clave 

número 2 ,pasa a ser primaria. 
En el rectángulo: £6 ,la clave 

número 2 ,Pasa a ser primaria. 
(Cuando esté listo para seguir dé INTRO) 
En el rectángulo: £7 ,la clave 

número 2 Pasa a ser primaria. 
En el rectángulo: £8 ,la clave 

número 2 ,Ppasa a ser primaria. 
En el rectángulo: £9 ,la clave 
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número 2 ¿pasa a ser primaria. 
En el rectángulo: £10 ,la clave 

número 2 ¿pasa a ser primaria. 
En el rectángulo: ENSEÑA ¿la clave 

número 2 ¿pasa a ser primaria. 
En el rectángulo: TUTOR ¿la clave 

número 2 ¿Pasa a ser primaria. 


Fin de designación de claves primarias 
Invocar a la Fase 7 (Regla de Agregación de Rects.) 
Empieza Agregación de Rects. 


El rect.: £l > 

ha sido agregado al: C4 5 

cuyo nuevo nombre es: C4 
El rect.: £3 A 

ha sido agregado al: CLASES z 

cuyo nuevo nombre es: CLASES 
(Cuando esté listo para seguir dé INTRO) 
El rect..: £4 ' 

ha sido agregado al: CLASES A 

cuyo nuevo nombre es: CLASES 
El rect.: £5 > 

ha sido agregado al: C10 A 

cuyo nuevo nombre es: c10 
El rect.: £6 A 

ha sido agregado al: C10 A 

cuyo nuevo nombre es: c10 
El rect.: £7 4 

ha sido agregado al: C10 ; 

cuyo nuevo nombre es: c10 
El rect.: £8 : 

ha sido agregado al: C9 7 

cuyo nuevo nombre es: C9 
El rect.: £9 A 

ha sido agregado al: C9 , 

cuyo nuevo nombre es: c9 
(Cuando esté listo para seguir dé INTRO) 
El rect.: £10 ; 

ha sido agregado al: CALIFICACS % 

cuyo nuevo nombre es: CALIFICACS 
El rect.: ENSEÑA o 

ha sido agregado al: GRUPOS ; 

cuyo nuevo nombre es: GRUPOS-ENSEÑA 
El Fect.:: TUTOR p 

ha sido agregado al: C9 ; 

cuyo nuevo nombre es: C9-TUTOR 
El rect.: C4 a 

ha sido agregado al: C1 4 

cuyo nuevo nombre es: C1-C4 


Fin de Agregar Rectángulos 
(17)¿Desea saltarse la Supresión de Rects.? (S/N): n 
Empieza Supresión de Rects. 


Suprimido el rectángulo: €2 
Suprimido el rectángulo: Cc3 
Suprimido el rectángulo: C6 
Suprimido el rectángulo: C5 
(Cuando esté listo para seguir dé INTRO) 
Suprimido el rectángulo: 7 
Suprimido el rectángulo: Cc8 
Suprimido el rectángulo: c1l 
Suprimido el rectángulo: c13 
Suprimido el rectángulo: c12 
Suprimido el rectángulo: c16 
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Suprimido el rectángulo: 
Suprimido el rectángulo: 
Empieza Supresión de asocs. impl. (n:n) 

*****Hay que hacer otra iteración (INTRO): 


(Iteración: 


ci5 
c14 


Empieza Definición de claves 


Fin de Definir 


Claves 


Empieza designación de claves primarias 
Fin de designación de claves primarias 
Empieza Agregación de Rects. 

Fin de Agregar Rectángulos 


Empieza Supresión de Rects. 


Empieza Supresión de asocs. impl. (n:n) 
RAKKKKKKKKKKAXKXETN DE FASE 7h XKKKKKKKKKKKKKKkXk 
**XXXFIN DE APLICACION DE REGLAS (FASES 6 Y 7) ***** 
(Cuando esté listo para seguir dé INTRO) 

*x*xxx*x Empieza FASE 8 (Eliminación claves redundantes) ***x* 
Empieza clasificación de mreat por rect. 
Fin de clasificación de mreat por rect. 


inore: 

Claves 
inore: 

Claves 
inore: 

Claves 
inore: 

Claves 
inore: 

Claves 
inore: 

Claves 
inore: 

Claves 
inore: 


1 
renumeradas 
3 
renumeradas 
10 
renumeradas 
17 
renumeradas 
18 
renumeradas 
19 
renumeradas 
20 
renumeradas 
22 


nclav: 2 
en mtrab 

nclav: 1 
en mtrab 

nclav: pl 
en mtrab 

nclav: pl 
en mtrab 

nclav: il 
en mtrab 

nclav: 1 
en mtrab 

nclav: xd 
en mtrab 

nclav: 1 


(Cuando esté listo para seguir dé INTRO) 
Claves renumeradas en mtrab 


inore: 


31 


nclav: 1 


Claves renumeradas en mtrab 
Fin eliminación claves red. 
KRAKKKKKKKKKKKKX FIN DE FASE 8 KKKKKKKKKKKKXXk 
KAKXKXKKKXKKKkXx FIN DE SUPR. CLAVES RED. ***XAXKAXKX 
***x* Empieza FASE 9 (Impresión del diseño obtenido) 
(15)¿Desea un informe del diagrama obtenido? (S/N): N 
¿Desea guardar en disco el diagrama final obtenido?(S/N):n 
KKKKKKKKKKKKKKX FIN DE FASE 9 KKKXKKKKXKKKKKKX 
XAKKKKKKXXKXx FIN DE IMPRIMIR INFORME XKKKKKKKX 


Ok 


Base de Datos Universitaria 


I.- ENTIDADES. 


(El tipo de Entidad, entre paréntesis, significa: 
F =Fuerte ; D =Dependiente ; A =de asociación). 


kk 
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Ent. núm. 1 (D) : ALUMNOS 
Ent. núm. 2 (F) : ASIGNATURAS 
Ent. núm. 3 (A) : CALIFICACS 
Ent. núm. 4 (D) : CLASES 
Ent. núm. 5 (A) : GRUPOS 
Ent. núm. 6 (A) : MATRICS 
Ent. núm. 7 (A) : PRERREQ 
Ent. núm. 8 (F) : PROFESORES 
Ent. núm. 9 (D) : TEXTOS 


II.- RELACIONES. 


***REL. núm. 1: ALUMNOS 
ATRIBUTOS: 


NOMBRE 
$PROF 


CLAVE NUM. 1 


***REL. núm. 2: ASIGNATURAS 


NOMBRE 
HASIG 


CLAVE NUM. 1 : 


NOMBRE 


CLAVE NUM. 2 : 


***REL. núm. 3: CALIFICACS 


ATRIBUTOS: 


***REL. núm. 4: CLASES 
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ATRIBUTOS: 


***REL. núm. 5: GRUPOS 


ATRIBUTOS: 


***XREL. núm. 


ATRIBUTOS: 


***REL. núm. 


ATRIBUTOS: 


6: 


Te 


MATRICS 


PRERREQ 


***REL. núm. 


ATRIBUTOS: 


HPROF 
NOMBRE 


8: 


PROFESORES 


Programa para diseño / 245 


E 


CATEG 
SUELDO 


CLAVE NUM. 1 : 


***REL. núm. 9: TEXTOS 


ATRIBUTOS: 


III.- ASOCIACIONES IMPLICITAS. 


**ASOC. NUM. 2: 


Relcn. origen :ASIGNATURAS 
Relcn. destino: TEXTOS 
Cardinalidad : (1 : m) 


Atributos comunes: 
1)Orig.:+fASIG 
Dest.:$ASIG 


**ASOC. NUM. 11: 


Relcn. origen :GRUPOS 
Relcn. destino:MATRICS 
Cardinalidad : (1 : n) 


Atributos comunes: 
1)Orig.:fASIG 
Dest.:$HASIG 
2)Orig.: GRUP 
Dest. : HGRUP 


**ASOC. NUM. 14: 


Relcn. origen :ASIGNATURAS 
Relcn. destino: PRERREO 
cárdinalidad “Y (1 :n) 


Atributos comunes: 
1)Orig.:fASIG 
Dest.:f$ASIG. 1 


**ASOC. NUM. LS: 
Relcn. origen :ASIGNATURAS 


Relcn. destino: PRERREQ 
Cardinalidad : (1 : n) 
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Atributos comunes: 
1)Orig.:*+ASIG 
Dest.:$fASIG. 2 


**ASOC. NUM. 17: 


Relcn. origen :ASIGNATURAS 
Relcn. destino:CALIFICACS 
Cardinalidad : (1 : m) 


Atributos comunes: 
1)Orig.:fASIG 
Dest.:HASIG 


**ASOC. NUM. 18: 


Relcn. origen :ASIGNATURAS 
Relcn. destino: GRUPOS 
Cardinalidad : (1 : n) 


Atributos comunes: 
1)Orig.:fASIG 
Dest.:$ASIG 


**ASOC. NUM. 21: 


Relcn. origen :GRUPOS 
Relcn. destino: CLASES 
Cardinalidad : (1 : m) 


Atributos comunes: 
1)Orig.:fASIG 
Dest.:fASIG 
2)Orig.: fGRUP 
Dest. : HGRUP 


**ASOC. NUM. 22? 
Relcn. origen :ALUMNOS 
Relcn. destino:CALIFICACS 
Cardinalidad : (1 : m) 
Atributos comunes: 
1)Orig.: fALUM 
Dest. : KALUM 
**ASOC. NUM. EE 


Relcn. origen :ALUMNOS 


Relcn. destino:MATRICS 
Cardinalidad : (1 : m) 


Atributos comunes: 
1)Orig.: tALUM 
Dest.:fALUM. 1 
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**ASOC. NUM. 34: 


Relcn. origen :PROFESORES 
Relcn. destino:GRUPOS 
Cardinalidad : (1 : n) 


Atributos comunes: 
1)Orig.:$PROF 
Dest. : HPROF 


**ASOC.. ¡NUM. 635: 
Relcn. origen :PROFESORES 
Relcn. destino: ALUMNOS 
Cardinalidad : (1 : n) 
Atributos comunes: 


1)Orig.: PROF 
Dest.: PROF 


IV.- CONDICIONES DE INTEGRIDAD. 


** 1).Los valores que toman la, o las, columnas: 
HASIG 
en las filas de la tabla: 
TEXTOS 
tienen que existir, y SIN repetirse, 
en las filas de la.tabla: 
ASIGNATURAS 
en la, o las, columnas: 
HASIG 
respectivamente. 


** 2).Los valores que toman la, o las, columnas: 
HASIG 
en las filas de la tabla: 
ASIGNATURAS 
tienen que existir, pudiendo REPETIRSE, 
en las filas de la tabla: 


TEXTOS 
en la, o las, columnas: 
HASIG 
respectivamente. 


** 3).Los valores que toman la, o las, columnas: 
HASIG 
HGRUP 
en las filas de la tabla: 
MATRICS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
GRUPOS 
en la, o las, columnas: 
HASIG 
FGRUP 
respectivamente. 
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** 4).Los valores que toman la, o las, columnas: 
HASIG. 1 
en las filas de la tabla: 
PRERREQ 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 


ASIGNATURAS 
en la, o las, columnas: 
HASIG 


respectivamente. 


** 5).Los valores que toman la, o las, columnas: 
$HASIG. 2 
en las filas de la tabla: 
PRERREQ 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
ASIGNATURAS 
en la, o las, columnas: 
HASIG 
respectivamente. 


** 6).Los valores que toman la, o las, columnas: 
HASIG 
en las filas de la tabla: 
CALIFICACS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
ASIGNATURAS 
en la, o las, columnas: 
RHASIG 


respectivamente. 


** 7).Los valores que toman la, O las, columnas: 
$HASIG 
en las filas de la tabla: 
ASIGNATURAS 
tienen que existir, pudiendo REPETIRSE, 
en las filas de la tabla: 
CALIFICACS 
en la, o las, columnas: 
RASIG 
respectivamente. 


** 8).Los valores que toman la, o las, columnas: 
HASIG 
en las filas de la tabla: 
GRUPOS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
ASIGNATURAS 
en la, o las, columnas: 
HASIG 
respectivamente. 


** 9).Los valores que toman la, o las, columnas: 
HASIG 
FGRUP 
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en las filas de la tabla: 
CLASES 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
GRUPOS 
en la, o las, columnas: 
HASIG 
HGRUP 
respectivamente. 


** 10).Los valores que toman la, o las, columnas: 
HASIG 
HGRUP 
en las filas de la tabla: 
GRUPOS 
tienen que existir, pudiendo REPETIRSE, 
en las filas de la tabla: 
CLASES 
en la, o las, columnas: 
HASIG 
$GRUP 
respectivamente. 


** 11).Los valores que toman la, o las, columnas: 
$ALUM 
en las filas de la tabla: 
CALIFICACS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
ALUMNOS 
en la, o las, columnas: 
$ALUM 
respectivamente. 


** 12).Los valores que toman la, o las, columnas: 
HALUM 
en las filas de la tabla: 
ALUMNOS 
tienen que existir, pudiendo REPETIRSE, 
en las filas de la tabla: 
CALIFICACS 
en la, o las, columnas: 
F$ALUM 
respectivamente. 


** 13).Los valores que toman la, o las, columnas: 
FHALUM. 1 
en las filas de la tabla: 
MATRICS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
ALUMNOS 
en la, o las, columnas: 
H+ALUM 
respectivamente. 
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** 14).Los valores que toman la, o las, columnas: 
$ ALUM ñ 
en las filas de la tabla: 
ALUMNOS 
tienen que existir, pudiendo REPETIRSE, 
en las filas de la tabla: 
MATRICS 
en la, o las, columnas: 
HALUM. 1 
respectivamente. 


** 15).Los valores que toman la, o las, columnas: 


$PROF 
en las filas de la tabla: 
GRUPOS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
PROFESORES 
en la, o las, columnas: 
$PROF 
respectivamente. 


** 16).Los valores que toman la, o las, columnas: 


$PROF 
en las filas de la tabla: 
ALUMNOS 
tienen que existir, y SIN repetirse, 
en las filas de la tabla: 
PROFESORES 
en la, o las, columnas: 
$PROF 
respectivamente. 


V.- PROTODEFINICIONES SQL. 


o 


**x** TABLAS E INDICES DE CLAVES: 


CREATE TABLE ALUMNOS 
(*ALUM NOT NULL 
,AÑO NOT NULL 
,|NOMBRE NOT NULL 
,HPROF NOT NULL 
) 


CREATE UNIQUE INDEX ALUMNOX1 
ON ALUMNOS 
(RHALUM 
) 


CREATE TABLE ASIGNATURAS 
(NOMBRE NOT NULL 
,HASIG NOT NULL 
) 
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CREATE UNIQUE INDEX ASIGNAX1 
ON ASIGNATURAS 

(NOMBRE 

) 


CREATE UNIQUE INDEX ASIGNAX2 
ON ASIGNATURAS 


(RASIG 
) 


CREATE TABLE CALIFICACS 
(F$ASIG NOT NULL 
,»FEXAM NOT NULL 
,+ALUM NOT NULL 


¿NOTA NOT NULL 
) 


CREATE UNIQUE INDEX CALIFIX1 
ON CALIFICACS 

($ASIG 

, REXAM 

, HALUM 

) 


CREATE TABLE CLASES 
(F$ASIG NOT NULL 
¿+GRUP NOT NULL 
,DIA NOT NULL 
,HORA NOT NULL 
,AULA NOT NULL 
) 


CREATE UNIQUE INDEX CLASESX1 
ON CLASES 

(RASIG 

, HGRUP 

¿DIA 

) 


CREATE TABLE GRUPOS 
(F$ASIG NOT NULL 
,RHGRUP NOT NULL 


¿HPROF NOT NULL 
) 


CREATE UNIQUE INDEX GRUPOSX1 
ON GRUPOS 
(RASIG 
, FGRUP 
) 


CREATE TABLE MATRICS 
(H$ALUM_1 NOT NULL 
,R+ASIG NOT NULL 


, GRUP NOT NULL 
) 
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CREATE UNIQUE INDEX MATRICX1 
ON MATRICS 
(HALUM_1 
, HASIG 
, HGRUP 
) 


CREATE TABLE PRERREQ 
(f$ASIG_1 NOT NULL 
,»RHASIG_2 NOT NULL 
) 


CREATE UNIQUE INDEX PRERREX1 
ON PRERREQ 
(RASIG_1 
,/RASIG_2 
) 


CREATE TABLE PROFESORES 
($ PROF NOT NULL 
,+NOMBRE NOT NULL 
,CATEG NOT NULL 
¿SUELDO NOT NULL 
) 


CREATE UNIQUE INDEX PROFESX1 
ON PROFESORES 
(F$PROF 
) 


CREATE TABLE TEXTOS 
(LIBRO NOT NULL 
,»RASIG NOT NULL 
) 


CREATE UNIQUE INDEX TEXTOSX1 
ON TEXTOS 
(LIBRO 
,/—RHASIG 
) 


**x*x*x INDICES PARA CONDS. DE INTEGRIDAD: 


CREATE INDEX TEXTOSY2 
ON TEXTOS 
(RASIG 
) 


CREATE INDEX CALIFIY17 


ON CALIFICACS 
($ASIG 
) 

CREATE INDEX CLASESY21 
ON CLASES 
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($ASIG 
, HGRUP 
) 

CREATE INDEX CALIFIY22 
ON CALIFICACS 
(RH ALUM 
) 

CREATE INDEX MATRICY33 
ON MATRICS 
(RALUM_1 
) 


XXKKXARKAXKXKXKX FIN DEL INFORME KAKKKKKKKKKKKKXX 
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Soluciones a los 


APENDICE 


ejercicios propuestos 


ALGEBRA RELACIONAL 


1) Sean las relaciones T y $ siguientes: 


R|AI|B S BE 
al|b b | e 
c.1b bld 
die ela 


Hallar los resultados de las siguientes expresiones: 


1.1) RUS. 
a |b 
Cc 106 
dle 
bic 
bid 
ela 
1.2) RS. 
a|b 
c|b 
de 
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1.3) Rx*S. 


2 


— 


1.4) P(A) (R). 


1.5) S(A=C) (Rx8). 


Sean las relaciones siguientes: 


a) HOMBRES (NOMH, EDAD) 


b 


C 


d 


e 


= 


== 


lo 


— 


Clave: (NOMH). 

Significado: Cada fila representa un hombre, cuyo nombre es NOMH, y su edad 
en años viene en EDAD. 

MUJERES (NOMM, EDAD) 

Clave: (NOMM). 

Significado: Cada fila representa una mujer, cuyo nombre es NOMM, y su edad 
en años viene en EDAD. 

HSIM (NOMH, NOMM). 

Clave: (NOMH, NOMM). 

Significado: El hombre NOMH cae simpático a la mujer NOMM. 


MSIM (NOMH, NOMM). 
Clave: (NOMH, NOMM). 
Significado: La mujer NOMM cae simpática al hombre NOMH. 


MATRIM (NOMH, NOMM). 


Clave: (NOMH, NOMM). 
Significado: La pareja NOMH y NOMM están casados. 
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Escribir las sentencias necesarias para responder a las preguntas siguientes: 


2.1) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos. 
HSIM n MSIM. 

2.2) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos, con 
edades entre 20 y 30 años y que no estén casados entre sí. 
(S(Q20 < HOMBRES.EDAD < 30) » (20 < MUJERES.EDAD < 30)) ((HSIM n 
MSIM) * HOMBRES * MUJERES)) —- MATRIM. 

2.3) Hallar los matrimonios en que ambos esposos se caen mutuamente simpáticos. 
HSIM A MSIM Nh MATRIM. 

2.4) Hallar las mujeres casadas a quienes no cae simpático su marido. 
P(NOMM) (MATRIM — HSIM). 

2.5) Hallar los hombres misóginos a quienes no cae simpática ninguna mujer. 
P(NOMH) (HOMBRES) —P(NOMH) (MSIM). 


2.6) Hallar los hombres y mujeres asociales a quienes no cae nadie simpático. 
(P(NOMH) (HOMBRES) —P(NOMH) (MSIM)) v(P(NOMM) (MUJERES) — 
P(NOMM) (HSIM)). 

2.7) Hallar las mujeres casadas que caen simpáticas a algún hombre. 

P(NOMM) (MSIM)—P(NOMM) (MATRIM). 

2.8) Hallar los hombres a quienes sólo caen simpáticas mujeres casadas. 

Sea MSIMNC (NOMH, NOMM) el conjunto de parejas de hombres con mujeres 
simpáticas no casadas. Será igual a: 
MSIMNC(NOMH, NOMM)=MSIM —(MSIM x«x PONOMM) (MATRIM)). 


La respuesta a la pregunta será: 
P(NOMH) (MSIM) —P(NOMH) (MSIMNO). 


Expresada en una sola fórmula queda: 
P(NOMH) (MSIM) —P(NOMH) (MSIM —(MSIM x* P(NOMM) (MATRIM)). 


Sean las relaciones siguientes: 


a) SOCIO (AFICIONADO, VIDEOCLUB). 
Significado: AFICIONADO es SOCIO de VIDEOCLUB. 


b) GUSTA (AFICIONADO, PELICULA). 
Significado: PELICULA de cine GUSTA a AFICIONADO. 


c) VIDEOTECA (VIDEOCLUB, PELICULA). 
Significado: VIDEOCLUB dispone en su VIDEOTECA de PELICULA. 


Escribir las sentencias necesarias para responder a las preguntas siguientes: 


3.1) Videoclubes que disponen de alguna película que le guste a José Pérez. 
P(VIDEOCLUB) (S(AFICIONADO =JOSE PEREZ) (VIDEOTECA « GUSTA). 


3.2) Aficionados que son socios al menos de un videoclub que dispone de alguna 
película de su gusto. 


P(AFICIONADO) (SOCIO + VIDEOTECA + GUSTA). 
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3.3) Aficionados que son socios solamente de videoclubes que disponen de alguna 


película de su gusto. 


P(AFICIONADO) (SOCIO) —P(AFICIONADO) (SOCIO —P(AFICIONADO, 
VIDEOCLUB) (SOCIO * VIDEOTECA * GUSTA). 


3,4) Aficionados que no son socios de nigún videoclub donde tengan alguna película 


de su gusto. 


P(AFICIONADO) (SOCIO) —P(AFICIONADO) (SOCIO * VIDEOTECA x 
GUSTA). 


4) Sean las relaciones siguientes: 
a) PRO (NP, NOMP, CIUDADP). 


b 


C 


d 


— 


= 


lo, 


Clave: (NP). 

Significado: Cada fila representa un Proveedor, cuyo identificador es NP, su 
nombre NOMP, y habita en la ciudad CIUDADP. 

ART (NA, DESA, COLOR, TALLA). 

Clave: (NA). 

Significado: Cada fila representa un Artículo, cuyo identificador es NA y su 
descripción DESA. 

FAB (NF, NOMF, CIUDADP). 

Clave: (NF). 

Significado: Cada fila representa una Fábrica, cuyo identificador es NF, su nombre 
NOME, y está situada en CIUDADF. 

PED (NP, NA, NF, CANTIDAD). 

Clave: (NP, NA, NF). 

Significado: Cada fila representa un Pedido del Artículo NA, al Proveedor NP, 
para la Fábrica NF. 


Escribir las sentencias necesarias para responder a las preguntas siguientes: 


4.1) Hallar los identificadores de todas las Fábricas. 


P(NF) (FAB). 


4.2) Hallar los nombre de las Fábricas situadas en Madrid. 


P(NOMF) (S(CIUDADF = MADRID) (FAB)). 


4,3) Artículos tales que ningún otro tiene talla más pequeña. 


Sean ART1=ART y ART2=ART (vamos a combinar las filas de ART consigo 
mismas): 
P(NA) (ART) —P(ARTI1.NA) (S(ARTI.TALLA >ART2.TALLA) (ART1 x ART2)) 


4.4) Proveedores que suministran a la Fábrica Fl. 


P(NP) (S(NF =F1) (PED)). 


4.5) Proveedores que suministran a la Fábrica Fl el Artículo Al. 


P(NP) (S((NF=F1) »(NA=A1)) (PED)). 


4.6) Nombres de las Fábricas a las que suministra el Proveedor Pl. 


P(NOMFP) (S(NP=P1) (PED) x« FAB)). 


4.7) Colores de los Artículos suministrados por el Proveedor Pl. 


P(COLOR) (S(NP=P1) (PED x FAB)). 
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4.8) Qué Proveedores suministran a las Fábricas Fl y F2. 
Sean PED1=PED y PED2=PED: 
P(NP) (S((PED1.NP=PED2.NP) , (PEDI1.NF=F1) 1 (PED2.NF =F2)) 
(PED1 x PED2)). 
O también: 
(P(NP) (S(NF=Fl1) (PED))) n (P(NP) (S(NF=F2) (PED))). 
4.9) Proveedores que suminstran Artículos azules a la Fábrica Fl. 
P(NP) (S((NF=F1) (COLOR =Azul)) (PED + ART)). 
4.10) Artículos suministrados a las Fábricas de Madrid. 
P(NA) (S(CIUDAD= Madrid) (PED x FAB)). 
4.11) Proveedores que suministran algún Artículo azul a las Fábricas de Madrid o 
Lisboa. 
P(NP) (S((CIUDAD= Madrid) v(CIUDAD=Lisboa)) (COLOR =Azul)) 
(PED * FAB « ART)). 
4.12) Artículos vull por Proveedores en cuya ciudad hay alguna Fábrica. 
P(NA) (PED «+ (P(NP) (S(CIUDADP =CIUDADEF) (PRO x FAB)))). 


4.13) Artículos suministrados a las Fábricas de Madrid por Proveedores de Madrid. 
P(NA) (S(CIUDADP= Madrid) A (CIUDADF= Madrid)) (PED x* PRO « FAB))). 


4.14) Fábricas abastecidas por al menos un Proveedor de distinta ciudad. 
P(NF) (S(CIUDADP= =CIUDADEF,) (PED x PRO x FAB)). 
4.15) Fábricas que no son abastecidas de Artículos azules por Proveedores de 
Madrid. 
P(NF) (FAB) —P(NF) (S(CIUDADP= Madrid) (COLOR = Azul) 
(PED x PRO x ART). 
4.16) Proveedores que suministran al menos un Artículo suministrado por al menos 
otro Proveedor que suministra al menos un Artículo azul. 
Sea R1=(Proveedores de Artículos azules): 
R1 (NP) =P(NP) (S(COLOR = Azul) (PED x ART)). 
Sea R2=(Artículos suministrados por los Proveedores de Artículos azules): 
R2 (NA) =P(NA) (PED *Rl1). 
Sea R3=(Proveedores de los Artículos de R2): 
R3 (NP) =P(NP) (PED + R2). 
En conclusión la fórmula que responde a la pregunta es: 
P(NP) (PED x* P(NA) (PED + P(NP) (S(COLOR = Azul) (PED x ART)))). 
4.17) Fábricas que usan al menos un Artículo suministrado por el Proveedor Pl. 
P(NF) (PED *(P(NA) (S(NP =P1) (PED)))). 
4.18) Parejas de ciudades tales que un Proveedor de la primera abastece a una Fábrica 
de la segunda. 
P(CIUDADP, CIUDADF) (PED x PRO * FAB). 
4.19) Obtener las tripletas de valores de «CIUDAD, NA, CIUDAD) tales que un 
Proveedor de la primera ciudad abastece el artículo NA a una Fábrica de la 


segunda ciudad. 
P(CIUDADP, NA, CIUDADF) (PED x* PRO + FAB). 
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4.20) Repetir la pregunta anterior, pero sin obtener las tripletas en que ambas ciudades 
son la misma. 


S(CIUDADP= =CIUDADF) (P(CIUDADP, NA, CIUDADF) 
(PED x* PRO x FAB)). 
4.21) Proveedores que suministran un mismo Artículo, al menos, a todas las Fábricas. 
P(NP) ((P(NP, NA, NF) (PED))/(P(NF) (FAB))). 
4.22) Fábricas que tienen como único Proveedor a Pl. 
P(NF) (S(NP=P1) (PED)) —P(NF) (S(NP= =P1) (PED)). 
4.23) Artículos que son suministrados a todas las Fábricas de Madrid (excluyendo los 
que sólo se suministran a algunas). 
(P(NA, NF) (PED))/(P(NF) (S(CIUDADF = Madrid) (FAB))). 
4.24) e que usan, al menos, todos los Artículos suministrados por el Provee- 
or Pl. 
(P(NF, NA) (PED)/(P(NA) (S(NP =P1) (PED))). 
4.25) O que usan sólo Artículos que pueden ser suministrados por el Provee- 
or Pl. 


(P(NF) (FAB)) —(P(NF) (PED « ((P(NA) (ART) —P(NP) (S(NP=P1) (PED))))). 
4.26) Fábricas abastecidas por el Proveedor P1 con todos los Artículos que éste 

suministra. 

(P(NP, NA, NF) (PED))/((P(NP, NA) (S(NP=P1) (PED))). 


4.27) Fábricas que obtienen del Proveedor Pl, total o parcialmente, todos los Artícu- 
los que usan. 
(P(NF) un ((P(NA, NF) (PED))—(P(NA, NF) (S(NP=P1) 
(PED)) 


4.28) Fábricas abastecidas por todos los Proveedores que suministran algún Artículo 
de color azul. 


(P(NF, NP) (PED))/(P(NP) (S(COLOR = Azul) (PED x ART))). 


5 


== 


Sean las relaciones siguientes: 


a) EMPM (AE, 4D, NOME, CAT, SUELDO). 
Hay una tupla por cada empleado destinado en Madrid. 


AE: Número de empleado. 
4D: Número de departamento en el que trabaja. 
NOME: Nombre del empleado. 
CAT: Categoría del empleado. 
SUELDO: Sueldo del empleado. 
Clave Primaria: AE. 


b) EMPL (4E, 4D, NOME, CAT, SUELDO). 
Hay una tupla por cada empleado destinado en Lisboa. 
Iguales atributos que EMPM. 


Todos los empleados de la empresa están, o bien en EMPM, o bien en EMPL. Un 
empleado no pude estar a la vez en EMPM y EMPL. 


Clave Primaria: 4E. 
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c) DEP (4D, NOMD, JEFE, ORG, LOCAL). 


Hay una tupla por cada departamento de la empresa, sea cual sea la ciudad donde 
se encuentre (Madrid o Lisboa). 


4D: Número de departamento. 
NOMD: Nombre del departamento. 
JEFE: Número de empleado del director del departamento. 
ORG: Número de departamento del que este departamento depende. Se supone 
que en el organigrama de la empresa cada departamento depende de otro, y 


solamente de él, en una estructura jerárquica. Naturalmente había de existir 
un departamento origen, que no depende de ningún otro. 


LOCAL: Dirección (es decir, ciudad, calle, número, planta) donde se encuentra 
ubicada la oficina del departamento. Algunos de estos locales son propiedad 
de la empresa y otros están alquilados. 


Claves: 4D, NOMD, JEFE. 
Clave Primaria: 4D. 


d) ALQ (LOCAL, CANTIDAD). 


Hay una tupla por cada local alquilado. Cada local debe contener al menos un 
departamento. 

LOCAL: El mismo significado que en DEP. 

CANTIDAD: Coste del alquiler del local. 


Clave Primaria: LOCAL. 


Preguntas: 

a) ¿Qué atributos no deben de tomar valores nulos de acuerdo con la regla de 
Integridad de Claves? (Integridad de Entidad). 

b) ¿Qué atributos son Claves Ajenas? (Integridad de Referencia). 


Pregunta a) 


Todos los atributos designados como Claves Primarias: EMPM.XE, EMPL.XE, 
DEP.4D y ALQ.LOCAL. 


Pregunta b) 
Todos los atributos cuyos valores no nulos deban de existir en la Clave Primaria de 
alguna relación, que son: 


e EMPM.XD (hace referencia a la Clave Primaria DEP.4D). 

e EMPL.4D (hace referencia a la Clave Primaria DEP.4D). 

e JEFE (hace referencia, o bien a la Clave Primaria EMPM.XE, o bien a la 
EMPL. 4 E). 

e ORG (hace referencia a la Clave Primaria DEP.4D). 


El atributo DEP.LOCAL no es una clave ajena aunque LOCAL sea Clave Primaria 
en ALQ, pues no todos los valores de DEP.LOCAL han de estar en ALQ.LOCAL. 
En cambio, todos los locales alquilados han de contener algún Departamento, por lo 
que todos los valores de ALQ.LOCAL han de existir en DEP.LOCAL. Sin embargo, 
esta condición de existencia no es una condición de Integridad de Referencia, en el 
sentido estricto en que suelen definirse este tipo de condiciones, pues el atributo 
referido, DEP.LOCAL, no es una clave primaria. 
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CALCULO RELACIONAL 


1) Sean las relaciones siguientes: 
a) HOMBRES (NOMH, EDAD). 


Clave: (NOMH).Significado: Cada fila representa un hombre, cuyo nombre es 
NOMH y su edad en años viene en EDAD. 

MUJERES (NOMM, EDAD). 

Clave: (NOMM). 

Significado: Cada fila representa una mujer, cuyo nombre es NOMM y su edad en 
años viene en EDAD. 

HSIM (NOMH, NOMM). 

Clave: (NOMH, NOMM). 

Significado: El hombre NOMH cae simpático a la mujer NOMM. 

MSIM (NOMH, NOMM). 

Clave: (NOMH, NOMM). 

Significado: La mujer NOMM cae simpática al hombre NOMH. 

MATRIM (NOMH, NOMM). 

Clave: (NOMH, NOMM). 

Significado: La pareja NOMH y NOMM están casados. 


b 


pad 


Cc 


a 


d 


pl] 


== 


e 


Escribir las sentencias necesarias para responder a las preguntas siguientes. 


En las fórmulas que siguen, h, m, c, hs y ms son tuplas variables que toman valores 
en las relaciones: 


DOM (h) = HOMBRES, DOM (m)= MUJERES, DOM(c)=MATRIM, 
DOM (hs) = HSIM, DOM (ms) = MSIM. 
1.1) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos. 
t]| HSIM(t) A MSIM (t). 
1.2) Hallar las parejas de hombres y mujeres que se caen mutuamente simpáticos, con 
edades entre 20 y 30 años y que no estén casados entre sí. 
t| HSIM(t) A MSIM(t) A (1MATRIM(t)) A 
3h((20<h.EDAD<30) , (h.NOMH =t.NOMH))) » 
]m((20 <m.EDAD<30) , (m.NOMH =t.NOMM))). 
1.3) Hallar los matrimonios en que ambos esposos se caen mutuamente simpáticos. 
t| HSIM (t) A MSIM (t) a MATRIM(t). 
1.4) Hallar las mujeres casadas a quienes no cae simpático su marido. 
t(, | Jc((c.NOMM=1t) A (Vhs(c— =hs))). 
1.5) Hallar los hombres misóginos a quienes no cae simpática ninguna mujer. 
ta | Gh(h.NOMH=1)) a (vms(ms.NOMH=— =1)). 


1.6) Hallar los hombres y mujeres asociales a quienes no cae nadie simpático. 


t, |(Eh(h.NOMH=1)) » (Vms(ms.NOMH—1))) v ((3m(m.NOMM =1)) 
A (Vhs(hs.NOMM>— =1)). 


1.7) Hallar las mujeres casadas que caen simpáticas a algún hombre. 
t, |(Ec(c.NOMM=t)) A (3ms(ms.NOMM =t)). 
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1.8) Hallar los hombres a quienes sólo caen simpáticos mujeres casadas. 
ty | Gh(h.NOMH=1t)) A (vms((ms.NOMH— =t) v ((ms.NOMH=1t) A 
(m(m.NOMM =ms.NOMM))))). 


Sean las relaciones siguientes: 


a) SOCIO (AFICIONADO, VIDEOCLUB). 
Significado: AFICIONADO es SOCIO de VIDEOCLUB. 


b) GUSTA (AFICIONADO, PELICULA). 
Significado: PELICULA de cine GUSTA a AFICIONADO. 


c) VIDEOTECA (VIDEOCLUB, PELICULA). 
Significación: VIDEOCLUB dispone en su VIDEOTECA de PELICULA. 


Escribir las sentencias necesarias para responder a las preguntas siguientes. 


En las fórmulas que siguen, s, g y v son variables que toman valores en los dominios: 
DOM (s) =SOCIO, DOM (g) = GUSTA, DOM (v)= VIDEOTECA. 


2.1) Videoclubes que disponen de alguna película que le guste a José Pérez. 
tu |3g 3v((g. AFICIONADO =José Pérez) A 
(g. PELICULA =v.PELICULA) a (v.VIDEOCLUB =1)). 
2.2) Aficionados que son socios al menos de un videoclub que dispone de alguna 
película de su gusto. 
t, | 3s 3v 3g((s. VIDEOCLUB=v.VIDEOCLUB) A 
(v. PELICULA =g.PELICULA) a (g. AFICIONADO =s.AFICIONADO)). 
2.3) Aficionados que son socios solamente de videoclubes que disponen de alguna 
película de su gusto. 
t, |Vs((s. AFICIONADO =t) v ((s. AFICIONADO =t) A 
Gv Jg((s. VIDEOCLUB=v.VIDEOCLUB) A 
(v. PELICULA =g.PELICULA) A (g.AFICIONADO =1))))). 
2.4) Aficionados que no son socios de ningún videoclub donde tengan alguna película 
de su gusto. 
t 1 | Vs((s. AFICIONADO =t) v ((s, AFICIONADO =t) A 
— (Bv 3g((s. VIDEOCLUB=v.VIDEOCLUB)» 
(v. PELICULA = g.PELICULA) » (g. AFICIONADO =t))))). 


Sean las relaciones siguientes: 


a) PRO (NP, NOMP, CIUDADP). 
Clave: (NP). 
Significado: Cada fila representa un Proveedor, cuyo identificador es NP, su 
nombre NOMP, y habita en la ciudad CIUDADP. 

b) ART (NA, DESA, COLOR, TALLA). 
Clave: (NA). 
Significado: Cada fila representa un Artículo, cuyo identificador es NA y su 
descripción DESA. 

c) FAB (NF, NOMF, CIUDADP). 
Clave: (NP). 
Significado: Cada fila representa una Fábrica, cuyo identificador es NF, su nombre 
NOME, y está situada en CIUDADF. 
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d) PED (NP, NA, NF, CANTIDAD). 
Clave: (NP, NA, NF). 
Significado: Cada fila representa un Pedido del Artículo NA, al Proveedor NP, 
para la Fábrica NF. 


Escribir las sentencias necesarias para responder a las preguntas siguientes. 


En las fórmulas que siguen, p, a, f, x, y, z, son variables que toman valores en los 
dominios: 
DOM (p)=PRO, DOM(a)=ART, DOM(f)=FAB, DOM(x)=DOM (y)= 
DOM (2) =PED. 
3.1) Hallar los identificadores de todas las Fábricas. 
ty ¡IFEÉNF=1). 
3.2) Hallar los nombres de las Fábricas situadas en Madrid. 
ta |¡IK(.NOMF =t) a (f.CIUDADF = Madrid)). 


3.3) Artículos tales que ningún otro tiene talla más pequeña. 
Para DOM(r)=ART: 
t¿|3a(a.NA=tA Vr(a.TALLA <r.TALLA)). 

3.4) Proveedores que suministran a la Fábrica Fl. 
t(|IxG.NP=tAx.NF=F1). 

3.5) Proveedores que suministran a la Fábrica Fl el Artículo Al. 
ti |ix(A.NP=tAx.NF=FlAx.NA=A1). 


3.6) Nombres de las Fábricas a las que suministra el Proveedor Pl. 
ta | x 3fA.NP=P1 a x.NF =f.NF AfINOMF =1)). 


3.7) Colores de los Artículos suministrados por el Proveedor Pl. 
t 1 Ix3a(x.NP=P1Ax.NA=a.NA » a.COLOR =t)). 


3.8) Qué Proveedores suministran a las Fábricas Fl y F2. 
ta |ExGNF=Fl A x.NP=1)) A Gx(x.NF=F2 1 x.NP =1)). 
3.9) Proveedores que suministran Artículos azules a la Fábrica Fl. 
ta |3x3a(x.NP=tAx.NF=FlAx.NA=a.NA » a.COLOR = Azul). 


3.10) Artículos suministrados a las Fábricas de Madrid. 
ta | Ax IN(x.NA =t a x.NF=f.NF Af.CIUDADF = Madrid)). 

3.11) ias que suministran algún Artículo azul a las Fábricas de Madrid o 

isboa. 

t | 3x 3f3a(x.NP=tAx.NA=a.NA Ax.NF=f.NF 1a.COLOR =Azul a 
(CIUDADF= Madrid v f.CIUDADF =Lisboa)). 

3.12) Artículos suministrados por Proveedores en cuya ciudad hay alguna Fábrica. 
ta | 3x Ip M(X.NA =t a x.NP=p.NP Af. CIUDADF =p.CIUDADP)). 


3.13) Artículos suministrados a las Fábricas de Madrid por Proveedores de Madrid. 


ta | 3x 3p3f£(x.NA =tAx.NP=p.NP Ax.NF=f.NF a p. CIUDADP= Madrid A 
f.CIUDADF= Madrid). 


3.14) Fábricas suministradas por al menos un Proveedor de distinta ciudad. 
t 13x 3p AA.NF=t A x.NP=p.NP ax.NF=f.NF 1 p.CIUDADP= =f.CIUDADP). 
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3.15) Fábricas que no son suministradas de Artículos azules por Proveedores de 
Madrid. 
tal | EAENF=0) A7(Gx ap da(x.NF=tAx.NA=a.NA nx.NP=p.NP A 
a.COLOR = Azul a p.CIUDADP = Madrid)). 


3.16) Proveedores que suministran al menos un Artículo suministrado por al menos 
otro Proveedor que suministra al menos un Artículo azul. 
t( | 3x 3y 3zJa(x.NP =tAx.NA=y.NA a y.NP=z.NP a 
z.NA=a.NA 2 a.COLOR = Azul). 


3.17) Fábricas que usan al menos un Artículo suministrado por el Proveedor Pl. 
ta |xIy(A.NF=tAx.NA =y.NA » y.NP=P1). 


3.18) Parejas de ciudades tales que un Proveedor de la primera abastece a una Fábrica 
de la segunda. 
to | 3p 4x(p.CIUDADP=tl AfCIUDADF=t2 1 p.NP=x.NP a x.NF=£f.NF). 


3.19) Obtener las tripletas de valores de (CIUDAD, NA, CIUDAD) tales que un 
Proveedor de la primera ciudad abastece el artículo NA a una Fábrica de la 
segunda ciudad. 
tal | Jp 3£3x(p.CIUDADP =tl Af.CIUDADF=t31p.NP=x.NP A 

NF=f.NF 1 x.NA =12). 


3.20) Repetir la pregunta anterior, pero sin obtener las tripletas en que ambas ciudades 
son la misma. 
tol | E Jf3Ix(p.CIUDADP =tl Af.CIUDADF=13Ap.NP=x.NP A 
F=f.NF Ax.NA=12 1t1= =13). 
3.21) Proveedores que suministran un mismo Artículo, al menos, a todas las Fábricas. 
ta 1|Gp(p.NP=1)) a Ga 3f3x(x.NP=t A x.NA=a.NA a x.NF =f.NF)). 


3.22) Fábricas que tienen como único Proveedor a Pl. 
ta | EFÉNF=1)) A (Vx(.NFZ =tv (x.NF=tp x.NP=P1)). 

3.23) Artículos que son suministrados a todas las Fábricas de Madrid (excluyendo los 
que sólo se suministran a algunas). 
t|Ga(a.NA=t) pa dl CIUDADF= = Madrid v (f CIUDADF= Madrid A 
x.NA=tAx.NF=f.NF)). 


3.24) Fábricas que usan, al menos, todos los Artículos suministrados por el Provee- 
dor Pl. 
ta | EFEÉNE =1)) a (Vx Jy(x.NP= =Pl v(x.NP=P11y.NF=tA y.NA=x. NA)). 
3.25) Fábricas que usan sólo Artículos que pueden ser suministrados por el Provee- 
dor Pl. 
ta | EFENE=0) a (Vx(x.NFZ =tv (x.NF=t A Jy(y.NA=x.NA A y.NP= P1))). 


3.26) Fábricas abastecidas por el Proveedor P1 con todos los Artículos que éste 
suministra. 
ta [Vx Iy.NP= =Pl v(x.NP=P11y.NA=x.NA n y.NP=P1 1 y.NF=1t)). 


3.27) Fábricas que obtienen del Proveedor Pl, total o parcialmente, todos los Artículos 
que usan. 
ta | ENENF=1)) a (Vx Jy(x.NF>Z =tv (1NF=taA y.NP=Pln y.NA=x.NA A 
y.NF =t))). 
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3.28) Fábricas abastecidas por todos los Proveedores que suministran algún Artículo 
de color azul. 


ta | EENF =1) a (vx(E 3y da(y.NP=x.NP » y.NA=a.NA »¿a.COLOR =Azul)) 
v ((y o =x.NP y. NA=a.NA ra.COLOR =Azul)) a (3z(z.NP=x.NP a 
z.NF =1))))). 


NORMALIZACION 


1) Sea el esquema R(A, B, C, D, E) con las dependencias: 
A>BC; BC>A; BCD>E; E>C. 
Normalizar R en FNBC. 
Diagrama de dependencias funcionales: 


Claves: (AD), (BCD), (BDE). 
Proyectando sobre los atributos de BC>A y E>C, en este orden, se produce la 
descomposición siguiente: 
e R1 (A, B, C). 
A>B; A>C; BC>A. 
Claves: (A), (BC). 
FNBC. 
e R2 (B, C, D, B). 
BCD>E; E->C. 
Claves: (BCD), (BDE). 
e R21 (E, C). 
ESC. 
Clave: (B). 
FNBC. 
e R22 (B, D, E). 
Clave: (BDE). 
FNBC. 


El resultado de la descomposición es: R1 (A, B, C), R21 (E, C) y R22 (B, D, E). En 
el proceso se ha perdido la dependencia BCD>+E. 
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2) Sean los atributos A (Agente), O (Oficina), 1 (Inversor), V (Clase de valor), N 
(Nominal) y D (Dividendo), y el esquema de relación R(A, O, I, V, N, D), con las 
siguientes dependencias: 


V>D; I>A; IV>N; A>0. 


Normalizar R en FNBC. 
Diagrama de dependencias funcionales: 


Clave: (IV). 
Proyectamos sobre los atributos de A>0: 
e Rl (A, O). 
A>0. 
Clave: (A). 
FNBC. 
e R2 (A, IL, V, N, D). 
IV>N; I>A; V>D. 
Clave: (IV). 


Proyectamos R2 sobre los atributos de V>D: 
e R21 (V, D). 
V>D. 
Clave: (V). 
FNBC. 
e R22 (A, I, V, N). 
IV>N; I>A. 
Clave: (IV). 


Proyectamos R22 sobre los atributos de I>A: 
e R221 (1, A). 
I>A. 
Clave: (D. 
FNBC. 
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e —R222 (I, V, N). 
IV>N. 
Clave: (IV). 
FNBC. 


El resultado de la descomposición es: R1 (A, O), R21 (V, D), R221 (I, A) y R222 
(L, V, N). Además se han preservado las dependencias. 


3) Sea el esquema R(A, B, C, D) con las dependencias: 
AB>D; C>D; AB>C; C>B. 
a) Normalizar R en FN3. ¿Se preservan las dependencias? 
Diagrama de dependencias funcionales: 


Claves: (AB), (AC). 
Proyectando sobre los atributos de C>D: 
e Rl (C, D). 
C>D. 
Claves: (C). 
FNBC. 
e R2 (A, B, C). 
AB>C; C>B. 
Claves: (AB), (AC). 
FN3 (pero no FNBC). 


El resultado de la descomposición es: R1 (C, D) y R2 (A, B, C). 


Aunque la dependencia AB>D desaparece en el proceso, no se pierde, pues es 
inferible de las que se han preservado: de AB>C y C>D se deduce por transitivi- 
dad que AB>D. 


b) Normalizar R en FNBC. ¿Se preservan las dependencias? 
Proyectando la R2 anterior sobre los atributos de C>B: 
e R21 (B, C). 
C>B. 
Claves: (C). 
FNBC. 
e R22 (A, C). 
Claves: (AC). 
FNBC. 
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El resultado de la descomposición es: R1 (C, D), R21 (B, C) y R22 (A, C). Se ha 
perdido la dependencia ABC. 


c) Aplicar a R el algoritmo que preserva dependencias. Comprobar que se obtienen 
relaciones FN3. 


Como AB>D es redundante, sólo consideramos las dependencias: AB>C y 
> 


Proyectando sobre ellas encontramos: 
e Rl (A, B, C). 
AB>-C; C>B. 
Claves: (AB), (AC). 
FN3 (no FNBO). 
e R2 (B, C, D). 
C>D; CB. 
Claves: (C). 
FNBC. 
Proyectando sobre la clave (AB): 
R3 (A, B). 
Claves: (AB). 
FNBC. 
Redundante con Rl. 


El resultado de la descomposición es: R1 (A, B, C) y R2 (B, C, D). 


4) Sea el esquema R (A, B, C, D, E) con las dependencias: 
A>BCDE; CD>E; CE>B. 
Normalizar R en FNBC. ¿Se preservan las dependencias? 


Diagramas de dependencias funcionales: 


Claves: (A). 
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Proyectando sobre los atributos de CD>E y CDB, en este orden, se produce la 
descomposición: 
e R] (C, D, E). 
CD>+E. 
Claves: (CD). 
FNBC. 
e R2 (A, B, C, D). 
A>BCD; CD>B. 
Claves: (A). 
e R21 (B, C, D). 
CD>B. 
Claves: (CD). 
FNBC. 
e R22 (A, C, D). 
A>CD. 
Claves: (A). 
FNBC. 
El resultado de la descomposición es: R1 (C, D, E), R21 (B, C, D) y ES e C, D). 
En el proceso han desaparecido las dependencias: A>B, As E y CE Las dos 


primeras son inferibles de las que se han preservado, pero la tercera no. Por tanto, 
hay pérdida de dependencias. 


5) Sea el esquema R (4, B, C, D, E, F) con las dependencias: 
DE>C; C>F; F>D; CE>A; EF>B. 
a) Normalizar R en FNBC. ¿Se preservan las dependencias? 
Diagramas de dependencias funcionales: 


Claves: (CE), (DE), (EF). 


Proyectando sobre los atributos de C>F y CD, en este orden, se produce la 
descomposición: 


270 / Soluciones a los ejercicios propuestos 


e Rl (C, P). 
C>F. 
Claves: (C). 
FNEC. 
e R2 (A, B, C, D, E). 
C>D; CE>A; CE>B; DE>C. 
Claves: (CE), (DE). 
e R21 (C, D). 
C>D. 
Claves: (C). 
FNBC. 
e R22 (A, B, C, E). 
CE>A; CE>B. 
Claves: (CE). 
FNBC. 
El resultado de la descomposición es: R1 (C, F), R21 (C, D) y R22 (A, B, C, E). 
En el proceso han desaparecido las dependencias: DE>C, F>D y EF>B. No se 
preservan las dependencias por tanto. 
b) Normalizar R en FN3. ¿Se preservan las dependencias? 
R ya está en FN3. 


6) Sea el esquema R (A, B, C, D, E) con las dependencias: 
C>A; A>BC; BCD>E; ESC. 
a) Normalizar R en FNBC. ¿Se preservan las dependencias? 


Diagrama de dependencias funcionales: 


Claves: (AD), (CD), (DE). 


Proyectando sobre los atributos de A>C, E>C y E>B, en este orden, se produce 
la descomposición: 
e Rl (A, C). 
A>C; CA. 
Claves: (A), (C). 
FNBC. 


Soluciones a los ejercicios propuestos / 271 


e R2 (B, C, D, E). 
C>B; E>C; BCD>E. 
Claves: (CD), (DE). 
e R21 (C, B). 
EC. 
Claves: (B). 
FNBC. 
e R22 (B, D, E). 
E>B. 
Claves: (DE). 
e R221 (B, E). 
E>B. 
Claves: (E). 
FNBC. 
R222 (D, E). 
Claves: (D, E). 
FNBC. 


El resultado de la descomposición es: R1 (A, C), R21 (C, E), R221 (B, E) y 
R222 (D, E). 


En el proceso han desaparecido las dependencias: A>B y BCD>E. No se 
preservan las dependencias por tanto. 


b 


== 


Normalizar R en FN3. ¿Se preservan las dependencias? 
Proyectando sobre los atributos de A>B se produce la descomposición: 
e Rl (A, B). 
A>SB. 
Claves: (A). 
FNBC. 
e —R2 (A, C, D, B). 
A>C; C>A; E>C; CD>E. 
Claves: (AD), (CD), (DB). 
FN3. 
El resultado de la descomposición es: R1 (A, B) y R2 (A, C, D, E). 


Se preservan las dependencias, pues aunque BCD>»E ha desaparecido, es inferible 
de las que quedan. En efecto: BCD>CD>+E, luego BCD>E. 


Cc 


pa 


Aplicar a R el algoritmo que preserva dependencias. Comprobar que se obtienen 
relaciones FN3. 


Empecemos substituyendo BCD>E por CD>+E, para tener un cubrimiento mini- 
mo (eliminamos el atributo B que es redundante). Partimos por tanto de: C>A; 
A>BC; CD>E; E>C. Se produce la descomposición: 
e Rl (A,C). 
A>C; C>A. 
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Claves: (A), (C). 
FNBC. 
R2 (A, B, C). 

A>B; A>C; C>A. 
Claves: (A), (C). 
FNEC. 
e R3 (C, D, E). 

CD>E; E>C. 

Claves: (CD), DE). 

FN3. 
e R4(C, E). 

E>-C. 
Claves: (E). 
FNBC. 
RS (A, D). 
Claves: (AD). 
FNBC. 
Como R4 es redundante con R3, el resultado es: R1 (A, C), R2 (A, B, C), R3 (C, 
D, E) y RS (A, D). 
Podemos comprobar que esta descomposición es reversible por yunción. Para ello 


representemos como tablero la DY*(AC, ABC, CDE, AD), y apliquémosle las 
dependencias dadas. Partimos del tablero: 


ALBO DP ES 


a — a — — 
a b cc — — 
=—_oc<cdoe 
a —— d — 
AIDA CARO O 
Apliquemos C>A: 

ATTB, ¿DE 
a — a — — 
a b c — — 
ar —= 00d dee 
a —— d — 


Apliquemos A>BC: 
AYBOS CAD: * E 


a b cc — — 
a b cc — — 
afrb.  Oosd. e 
ar bo dd “= 


Vemos que aparece la fila <abcde». Por tanto, es reversible. 
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7) Añadir a la relación siguiente las filas necesarias para que se cumplen en ella las DPs: 
A>BC; CD>BE. 


A BA ED” E 
IND code 
a. 1 Cr DE 
IDO Cd Ta 


3 Er añadir las filas: (abc2e», <alcde», <abcd4», <(alcd4», <3bcde», <31cde> y 
1cd4>. 


8) Sea el esquema R (A, B, C, D, E) con las dependencias: 
A>BC; DE>>C. 


Demostrar que AD>»BE. 


pu 


De A>»BC, por complementación, se infiere: A>DE. 
De A>DE y DE>>C, por transitividad: A>(C— DE), es decir, A>C. 
De AD>»A (reflexividad), y A>C, por transitividad: AD>C. 
De AD>»C, por complementación: AD>»BE, c.q.d. 
También podemos utilizar el algoritmo de batida y la representación de AD>BE 


mediante tableros. En efecto, esta dependencia es representable como la DY *(ADBE, 
ADC). Representémosla con un tablero: 


A. B- “CRD. SE 
a hb e 
E RS 
A PUES? A 


Apliquémosle A>BC: 


AYTB CD JE 
dl 302 > 15 Ed We 
20 Y EEN ds 
32 «bye OS 
E IS 


Apliquémosle DE>C: 


Vemos que aparece la fila (abcde», c.q.d. 
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9) En el esquema del ejercicio 2 anterior queremos guardar la historia de los dividendos 
de cada tipo de valor. Entonces, en vez de cumplirse V>D, tendremos V=D. 


Normalizar R en FN4. ¿Se preservan las dependencias? 
Diagrama de dependencias funcionales: 


Claves: (IV). 
Proyectando sobre los atributos de V>D, A>0 e I>A, en este orden, se produce 
la descomposición: 
e R1 (V, D). 
Claves: (VD). 
FNBC, y también FN4 al no haber DPs. 
e R2 (A, O, L V, N). 
I>A; A>0; IV>N. 
Claves: (IV). 
e R21 (A, O). 
A>0. 
Claves: (A). 
FNBC (y FN4). 
e R22 (A, I, V, N). 
I>5A; IV>N. 
Claves: (IV). 
e R221 (I, A). 
I>5A. 
Claves: (1D). 
FNBC (y FN4). 
R222 (I, V, N). 
IV>N. 
Claves: (IV). 
FNBC (y FN4). 
El resultado de la descomposición es: R1 (V, D), R21 (A, O), R221 (L A) y R222 
(L, V, N). 
Se han preservado las dependencias. 


10) Sea el esquema R (4, B, C, D, E, F) con las dependencias: 
A>BCD; B>AC; C>D. 
Normalizar R en FN4. ¿Se preservan las dependencias? 


Soluciones a los ejercicios propuestos / 275 


P 


Diagrama de dependencias funcionales: 


Claves: (B). 
Proyectando sobre los atributos de A>BCD y CD, en este orden, se produce la 
descomposición siguiente: 
e Rl (A, B, C, D). 
B>A; B>C; C>D. 
Claves: (B). 
e R2 (A, E, FP). 
Claves: (AEF). 
FNBC y FN4. 
e R1] (C, D). 
C>D. 
Claves: (C). 
FNBC y FN4. 
e R12 (A, B, C). 
B>A; B>C. 
Claves: (B). 
FNBC y FN4. 
Se ha llegado así al esquema R11 (C, D), R12 (A, B, C) y R2 (ASE, E): 
Se preservan las dependencias. 


11) Sea el esquema R (A, B, C, D, E) con las dependencias: 
A>BC; D>C. 
a) Demostrar que A>C. 


De A>»BC y D>-C, y teniendo en cuenta que BC y D no tienen atributos 
comunes, y que C está contenido en BC, se deduce que AC. 


También puede deducirse aplicando el algoritmo de batida. 
Tablero inicial (AC): 


A” BE DE 
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Aplicamos A>BC: 


huauw|y 
Du | m 


AIFB: ¿E. DIE 
va RD 3 
a 2 “De fá.. 0 
añ 27 1D. 03,5 
aa Tb de 6 


Vemos que siempre que se repite A se repite también C, luego A=C, c. q. d. 
b) Normalizar R en FN4. ¿Se pierden dependencias? 
Claves: (ABDE). 
Proyectando sobre los atributos de A>BC y A>-C, en este orden, se produce la 
descomposición siguiente: 
e R] (A, B, C). 
A=SC. 
Claves: (AB). 
e R2 (A, D, E). 
Claves: (ADE). 
FNBC y FN4. 
e R1l (A, C). 
A>SC. 
Claves: (A). 
FNBC y FN4. 
e R12 (A, B). 
Claves: (AB). 
FNBC y FN4. 


Se ha llegado así al esquema R11 (A, C), R12 (A, B) y R2 (A, D, E). 
Se ha perdido la dependencia D>-C. 


12) Sea la siguiente extensión de R (A, B, C): 
A B C 


OQOCTCOoOp 
UU 42 UY UN — 
mmuam > 
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a) ¿Satisface esta extensión de R la DY: *(AB, AC, BC)? 


Si se proyecta sobre AB, AC y BC, y se ayuntan estas proyecciones, se recompone 
la extensión dada. Por tanto, ésta satisface la DY. 


b) Añadimos a esta extensión la fila <f1B>. Añadir las filas que sean necesarias para 
que se siga cumpliendo la DY anterior. 


Hay que añadir la fila <a1B>. 


13) Sea el esquema R (A, B, C, D, E) con las dependencias: 
AB>C; C>E; E>C; C>D; AB>E. 
a) ¿Está R en FNBC? 
Diagrama de dependencias funcionales: 


Claves: (AB). No está en FNBC. 


b) Descomponemos R por proyecciones en R] (A, B, C), R2 (A, D, E) y R3 (C, E). 
¿Es esta descomposición reversible por yunción? 


Para que lo sea, la DY *(ABC, ADE, CE) tiene que ser inferible de las dependen- 
cias funcionales dadas. Para comprobar si es así puede utilizarse el algoritmo de 
batida. 


Tablero inicial: 


Apliquémosle la dependencia C>E: 


A BAC DLE 


a ib. cie 6 
a == d e 
== ca —o.e 


al bo Wermd- 8 
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Apliquémosle la dependencia E>C: 


A TB.) CC DE 


av Db cu =. 6 
a = 0 .d € 
= =—c— e 


a bic; dde 
Apliquémosle la dependencia C>D: 


A ABC DD, E 
A > 
a — Fe de 
=—_ocdoe 


ar DIC Ada "Le 


Aparece en el tablero la fila <abcde>. Por tanto, la DY es inferible de las 
dependencias funcionales dadas. 


c) ¿Preserva las dependencias? 


po 


Dependencias preservadas en el esquema final: 
R1: AB>C. 
R2: E>D. 
R3: C>E; E>C. 
Dependencias que han desaparecido: AB>E y C>D. Pero son inferibles de las 
preservadas, por lo que no se pierden dependencias. 
d) Normalizar R1, R2 y R3 en FNBC. 
R1 está ya en FNBC, pues su clave es (AB). 
Lo mismo ocurre con R3, cuyas claves son (C) y (E). 
R2 la descomponemos proyectando sobre los atributos de E>D: 
e R21 (D, E). 
E>.D. 
Claves: (E). 
FNBC. 
e R22 (A, E). 
Claves: (AB). 
FNBC. 


Se ha llegado así al esquema R1 (A, B, C), R21 (D, E), R22 (A, E) y R3 (C, E). 
Se han preservado las dependencias. 


14) Sea el esquema R (A, B, C, D, E) con las dependencias: 
A>C; B>C; C>D; DE>C; CE>A; x*(AD, AB, BE, CDE, AB). 
a) Hallar las claves. 
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Diagrama de dependencias funcionales: 


Claves: (BE). 


b) ¿Es la DY inferible de las DFs? 
Para comprobar si es así utilizaremos el algoritmo de batida. 
Tablero inicial: 


A BUE” Dy E 


2 ¿0 = 
a b — — — 
—M Da = 16 
— O A O 
a — 46 


a but. “d se 


Apliquémosle la dependencia A>C: 


A BCE DE 


a — 1l d — 
a b 1 —— 
=z b —— e 
=z—_ocdoe 
a — 1l — € 


a. 6 de 


Apliquémosle la dependencia BC: 
AUAB EE "DD, E 


a — 1 d — 
a b 1 — — 
— b l1l— e 
=z—_oc<c dose 
a = 1l — e 


ar. DE die 
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Apliquémosle la dependencia C>D: 


ASEB CAD ARE 
a — 1 d — 
a bi. lid. = 
—* bi 1 Md e 
=z—_oc dee 
a — 1d. e 
E A 


Apliquémosle la dependencia DE=C: 


ACB UD E 
a — cc d — 
a be. d — 
— Mb" ¿CF ¡dese 
== oc de 
ar—=. rd e 
a bread e 


Apliquémosle la dependencia CE>A: 


A PBASCED . “E 
a — ec d — 
= ,bYcrdád = 
an bocata Wee 
2 6 Md, € 
a —.ca.d e 
O A A 


Aparece en el tablero la fila <abcde>. Por tanto, la DY es inferible de las 
dependencias dadas. 


c) Las dependencias definidas por las claves son: BE>ABCDE. 


Si las aplicamos al tablero inicial éste no cambia. Por tanto, la DY no es inferible 
de las claves. 


A la misma conclusión se llega directamente viendo que ninguna intersección entre 
los componentes de la DY: AD, AB, BE, CDE y AE, contiene a la clave. 

d) ¿Está R en FNS? 
No, puesto que la DY no es inferible de las claves. O, desde otro punto de vista, 
como no está en FNBC tampoco puede estar en FNS5. 

15) Sea el esquema R (A, B, C, D, E) con las claves: 

K1: (BCE); K2: (ABE). 

Decir si son inferibles de las claves las DYs siguientes: 

a) *(ABCE, BCDE). 
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Las dependencias definidas por las claves son: 
BCE>ABCDE y ABE>ABCDE. Apliquemos una batida. 


Tablero inicial: 


AB O DE 


a Da ie 
= 1D. 1.Cc. de 
a DD e pides 


Apliquémosle la dependencia BCE>ABCDE: 


ACB ED E 
abbr. date 
ar DojOrdY Le 
IND er a me 


Aparece en el tablero las fila (abcde». Por tanto, la DY es inferible de las claves. 

Podemos deducir esto mismo mediante el algoritmo de Fagin. Como ambos 
componentes de la DY incluyen a la calve K1 los reagrupamos obteniendo la 
DY + (ABCDE). Esta DY incluye todos los atributos de R. Por tanto la DY dada 
es inferible de las claves. 


b) «(ABCE, BDE, ACD). 


Al aplicar las dependencias al tablero éste no cambia. Por tanto la DY no es 
inferible de las claves. 


A la misma conclusión se llega directamente viendo que ninguna intersección entre 
los componentes de la DY: ABCE, BDE y ACD, contiene a una clave. 


C 


* (ABCE, BCE, ABDE). 
Apliquemos una batida. Tablero inicial: 


A" BAR E:" Di “E 


a b cc — € 
=—=bcac-— ee 
ar Di... dut 
dy HDi 04. ¡die 


Apliquémosle la dependencia BCE=>ABCDE: 
A BAC GD WE 


aji Do varo e 
A OS A 
a b —d e 
2 “br e 
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Apliquémosle la dependencia ABE>ABCDE: 


A BLUE Di E 
o a EE 
A DIE ida e 
qu Dr AC RO 
a mbr ic: die 


Aparece en el tablero la fila <abcde>. Por tanto, la DY es inferible de las claves. 


Apliquemos el algoritmo de Fagin. Los dos primeros componentes incluyen 
a la clave K1. Los reagrupamos: *(ABCE, ABDE). Ahora incluyen a K2. Los 
reagrupamos: *x(ABCDE). Esta DY incluye a todos los atributos de R. Por tanto 
la DY dada es inferible de las claves. 


16) En el esquema del ejercicio 2 anterior descomponemos R por proyecciones en Rl (V, 
D), R2 (1, A), R3 (1, V, D) y R4 (4, O). ¿Es esta descomposición reversible por 
yunción? 


No puede serlo porque no incluye todos los atributos (falta N). 


17) En el esquema del ejercicio 2 anterior descomponemos R por proyecciones en R1 (1, V, N), 
R2 (1, A), R3 (V, D) y R4 (1, V, 0). ¿Es esta descomposición reversible por yunción? 
¿Preserva las dependencias? 


Será reversible si la DY * (IVN, IA, VD, IVO) es inferible de las dependencias dadas. 


Apliquemos una batida. Tablero inicial: 


AO" LV IN TD 


2 — AV. MA == 
a 1 

V d 
==. 0 1, Y == 


A 1 O A! 


Apliquémosle la dependencia V>D: 
AO ANITA N.D 


— — 1 Md 
a 1 

V d 
== o ivk— id 
dl OL A VA dl 


Apliquémosle la dependencia 1>A: 
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AFTO" T> VW, N.D 
a E y dl 
a i 

v d 
a Lo Mitrv =**4d 


E 
Apliquémosle la dependencia IV>N: 
A. ¿OMG Ve NSD 


MA O e, dl 
a i 


V d 
a O "Via dl 


a Moa a A 


Aparece en el tablero la fila <aocivnd). Por tanto, la DY es inferible de las claves. 
Dependencias preservadas: 


e Rl: IV>N. 
e R2: I>A. 
e R3: V>D. 
e R4: 1>0. 


Ha desaparecido A>0. Por tanto, no se preservan las dependencias. 


18 


pd 


Sea el esquema R (A, B, C, D, E). Los atributos (ABC) y (ABD) toman valores que 
no se repiten (es decir, son claves o superclaves). Además, se verifica AB>>C. Hallar 
una clave de R. 


Como AB>C y ABD>-C, y además C y ABD no tienen atributos comunes, se infiere 
que AB>-C. 


Por otra parte, de ABC se infiere, por complementación, que AB>DE. De aquí y 
de ABC>D, y teniendo en cuenta además que D está contenido en DE, y que ABC 
y DE no tienen atributos comunes, se infiere que AB>D. 


Análogamente, de AB>DE y ABC>E, se infiere AB>E. 
Por tanto, AB>ABCDE, luego (AB) es una clave de R. 
Podemos comprobarlo mediante el algoritmo de batida. 
Dependencias de partida: 

ABC>DE; ABD>CE; AB>C. 
Dependencia que hay que estudiar: AB>CDE. 


Tablero inicial: 


AS BB 8: D E 
ab cl dl el 
an c2 d2 e2 


cl=c2 dl=d2 el=e2 
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Apliquemos la dependencia AB>C: 


A BE D E 
ap vc dl el 
da. Di 62 d2 e2 
a. "bh, “e2 dl el 
a. bel d e2 


Apliquemos la dependencia ABC>DE: 
A B C D E 


a tbrcl dl el. 
au "b: $62 dl el 
E dl el 
a Dr “cl dl el 


Apliquemos la dependencia ABD>-CE: 


A “BG D E 


b cl dl el 
biPiel dl el 
el 
b cl dl el 


Doa 
o 
o 
=— 
a 
— 


Todas las veces que se repite AB, se repiten CDE. Por tanto, se verifica AB>CDE. 


Sea el esquema de relación MATRIM (H, M, S, FB, FD), con el significado siguiente: 
En MATRIM hay una fila por cada matrimonio celebrado en el país desde 1970. 


Atributo H: Nombre del marido. Se supone que no hay personas diferentes con igual 
nombre. 


Atribúto M: Nombre de la mujer. 
Atributo S: Situación del matrimonio. Puede ser una de las siguientes: 
e C: Casados todavía. 
e D: Ya divorciados. 
e S: Separados. 
e F: Alguno de los cónyuges, o ambos, han fallecido. 
Atributo FB: Fecha de la boda. 


Atributo FD: Fecha de disolución del matrimonio, bien por separación o divorcio, 
bien por fallecimiento de uno o ambos cónyuges. 


Enunciar las condiciones de integridad que lógicamente deberán cumplir todas las 
extensiones válidas de MATRIM. 


Deberán cumplirse las condiciones siguientes: 
a) Los valores de FB y FD deben ser fechas válidas (por ejemplo, el número de mes 


debe estar entre 1 y 12, si el mes es 1 el número de días debe estar entre 1 y 31 
etcétera.). 
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b) El atributo S sólo puede tomar uno de los valores C, D, S o F. 
c) Los atributos FB y FD deben ser fechas posteriores a 31 de diciembre de 1969. 


d) En todas las filas en que el atributo S tiene el valor C, FD debe ser nulo. En las 
demás debe ser no nulo. 


e) En todas las filas en que FD no es nulo, debe ser posterior a FB. 


f) Si en el país son ilegales la poligamia y la poliandria, en las filas que tienen en $ 
el valor C no pueden repetirse los valores de H o M. Dicho de otra forma, si 
seleccionamos todas las filas en que S tiene el valor C, los atributos H y M son 
claves. 


g) Suponiendo que un cambio de sexo oblique legalmente a cambiar también el 
nombre, ningún valor de H puede repetirse en M, y recíprocamente. 


h) Sea una fila cualquiera que tiene en el atributo S el valor F, y sean h, m y f los 
valores de sus columnas H, M y FB, respectivamente. Deberá cumplirse al menos 
una de las dos condiciones siguientes: 


e Para toda otra fila en que H tenga el valor h, el valor de FD debe ser 
anterior a f. 

e Para toda otra fila en que M tenga el valor m, el valor de FD debe ser 
anterior a f. 


i) Supongamos que extraemos todas las filas en que se repite un valor cualquiera de 
H y las clasificamos por FB creciente. Deberán cumplir las condiciones siguientes: 


e No puede haber más de una fila que tenga en S el valor C. Si la hay, debe 
ser la última. 

e Suponiendo que legamente no puede volver a casarse una persona sin 
obtener previamente el divorcio o enviudar, no podrá haber más de una fila 
que tenga en el atributo S el valor S, y si la hay, debe ser la última. 

e Toda fila deberá tener un valor en FB posterior al de FD en la fila 
precedente. 


j) La condición anterior es también aplicable si consideramos M en vez de H. 


k) Suponiendo que para la concesión del divorcio sea necesario un período previo 
de separación de un mínimo de dos años, deberá cumplirse que en todas las filas 
en que el atributo S contenga el valor D, el valor de FD deberá ser posterior al 
de FB en dos años o más. 


I) Siempre que se actualicen valores en una fila deberán cumplirse las condiciones 
siguientes: 


e Si el atributo S tiene el valor C, éste puede cambiar a S o F. En este caso 
también cambiará FD. 


e Si el atributo S tiene el valor S, éste puede cambiar a C, D Ó F. En este caso 
también cambiará FD, y si además S tenía S y cambia a D, el nuevo valor 
de FD deberá ser posterior al FD antiguo en dos o más años. Si S cambia 
del valor S al C, el nuevo valor de FD será nulo. 


e Si el atributo S tiene el valor F, ningún campo de la fila puede cambiar. 
e Si el atributo S tiene el valor D, ningún campo de la fila puede cambiar. 


e Siempre que cambie FD, el nuevo valor deberá ser posterior al que tenía, 
si ambos valores, el viejo y el nuevo, son no nulos. 
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DIAGRAMAS PARA DISEÑO 


En los ejercicios siguientes, para simplificación de los dibujos, dejaremos a veces las 
asociaciones explícitas sin nombre. En este caso indicaremos que son explicitas adjuntán- 
doles el signo 4. También, por la misma razón, se omitirán a veces los nombres de los 
conjuntos de valores representados en los rectángulos. 


1) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 


Aplicando las reglas de transformación se llega a la relación R (-A—, -B-, X). 


2) Transformar el diagrama siguiente: 


Se transforma en: 


m 
R3 (-A,B,C-,X) 
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3) Transformar el diagrama siguiente: 


Se transforma en: 


4) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 


Aplicando las reglas de transformación, se llega a las relaciones siguientes: 
R1 (A-, X); R2 (EB-, A, Y); R3 (-C-, B); R4 (-D-, C); RS (HE-, C). 
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5) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 


Aplicando las reglas de transformación, se llega a las relaciones siguientes: 
Rl (B-, A, E); R2 (-C-, B, D); R3 (-D-, E); R4 (FF, C). 


| 6) Obtener las entidades definidas por el diagrama siguiente y decir de qué tipo son: 


Propagando las clases y suprimiendo rectángulos se llega a: 


R1 (-A-,S,T) 


R2 (-B-,U,V,A) 


o, 


| R3 (-C-,W,X,B) R4 (-D-,Y,Z,B) 
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Entidades: R1 (Independiente); R2 (Asociativa); R3 y R4 (Dependientes). 
R2 y R3 son interdependientes. 


7) Obtener las entidades definidas por el diagrama siguiente y decir en qué tipo son: 


Propagando las claves y suprimiendo rectángulos se llega a: 


R1 (-A-,S,T) 
R2 (A ,B-,U.N) 
n n 
R3 (-A,B,C—,W,X) R4 (-A,B,D-.Y,Z) 


Entidades: R1 (Independiente); R2, R3 y R4 (Dependientes). 
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Expresión de este modelo en estructuras IMS: 


S1 (-A-,S,T) 
S2 (-B-,U.,V) 
S3 (-C-,W,X) S4 (-D-,Y,Z) 


8) Obtener las relaciones y claves del esquema de diseño a partir del diagrama siguiente: 


Transformando las asociaciones explícitas en implícitas y aplicando las reglas de 
transformación, se llega a las relaciones siguientes: 


R1 (A, B); R2 (B, C); R3 (-C-, U); R4 (-Y-, Z); RS (-F-, Y, E); R6 (-D, F>, X); 
RED O, Y, W) 


> . 
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9) Partimos del diagrama siguiente. Además de las asociaciones representadas en él hay 
otras dos: S y T. La primera entre los elementos de Cl y R, con cardinalidad (1: m). 
La segunda entre los elementos de C2 y R, con cardinalidad (m:m). Representar S 
y Ten el diagrama, obtener el esquema de diseño y decir de qué tipo son las Entidades 


obtenidas: 


(C) 


C2 (F) 
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El diagrama relacional de diseño será el siguiente: 
Relaciones: R1(-B-, A, C, D, E); R2(E-, G, H); T (B, F). 
Otras condiciones: R1[E]<R2[E]; R1[B] =T[B]. 


La Entidad R2 es fuerte, la T es débil y la R1 es de asociación. Además R]1 y T son 
interdependientes. 
10) Sean dos relaciones, A(X, Y, Z) y R(X, Y, W). La asociación implícita entre A y B 
según X es de cardinalidad (m: 1), según Y es de cardinalidad (m:c), y según (X, Y) 
es de cardinalidad (m:c). Comprobar que estas cardinalidades no son contradictorias 
y poner un ejemplo de extensiones de ambas relaciones que las cumplan. 


Según la tabla de cardinalidades de las asociaciones totales, combinando 1 con c se 
obtiene que la cardinalidad de A a B según (X, Y) puede valer c ó 0. Para la 
combinación m con m,la tabla da como posible cualquier valor (n, m, c, 1 ó 0). Por 
tanto, las cardinalidades dadas son posibles. 


po 


Ejemplo de valores: 


ARO Y- 2) y 1X- YoW) 
il “aro LAS 20 
il Lar 1 2 6 21 
E 
DR ES 


11) Transformar el diagrama siguiente: 


El rectángulo E participa con todos sus atributos en todas sus asociaciones, y en una 
de ellas con cardinalidad (m: 1). Por tanto, es suprimible. Para no perder informa- 
ción, hallamos las cardinaliades compuestas, mediante las tablas correspondientes. 
Así,la cardinalidad de la asociación implícita entre A y B, la hallamos componiendo 
las de (A-E) y (B-E). El resultado de aplicar las tablas es que de A a B, la cardinalidad 
puede valer c, 1 6 0, y de Ba A, puede valer n o c. Nos quedamos con los valores 
más generales, con lo que la cardinalidad compuesta entre A y B será (n:c). 
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Análogamente, las cardinalidades compuestas entre A y C, y A y D, son (m:c). 
También podríamos hallar las cardinalidades entre C y D, C y B, y B y D, pero no 
es necesario porque son consecuencia de las anteriores. En conclusión, el diagrama 
queda transformado en el siguiente: 


12) Transformar el diagrama siguiente: 


D (X,V) 
Cc 


A (X.Y) E (X) 


m 
C (X,W) 


El atributo X es clave en C. Agregando C y E se obtiene el diagrama siguiente: 
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13) Dado el siguiente diagrama, decir si la asociación explícita R3 es el producto de las 
asociaciones R1 y R2. 


A (-X-,X1) B1EY=Y1) C (-2-,Z1) 


Si R3 fuera el producto de R1 y R2, su cardinalidad vendría condicionada por las 
de éstas. Aplicando la tabla de producto de cardinalidades, tenemos que el camino 
A-R1-B-R2-C, combinando con 1, da como valor posible sólo c. Por tanto, R3 no 
puede ser el producto de Rl y R2. 


14) Decir si la asociación implícita entre A y C es redundante en el diagrama siguiente: 


Las cardinalidades de las asociaciones (A-B) y (B-C) no se pueden componer, pues 
intervienen en ellas atributos diferentes (Y y Z). La información aportada por el 
diagrama no permite afirmar si es redundante. En general no lo será. Ejemplo de 


valores: 
X Y Ya iZ TARO 
lara b A A 3 
lb c B B; 3 
DAA: d E 6,43 
DN E D 3 
4. 3d D 4 


Si fuera redundante significaría que al ir de A a B y de B a C, se asociarían las 
mismas tuplas que yendo directamente de Á a C. Por tanto sería necesario (no 
suficiente) que yendo de A a B y de B a C se obtuvieran iguales valores de X. Ejemplo: 


X Y Ya Z Do ES 
LA DA Al 
2 (e c B B 2 
4d dE E 4 
32 a D 6 
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15) Decir si la asociación implícita entre A y C es redundante en el diagrama siguiente: 


La asociación (A-C) puede obtenerse componiendo las asociaciones (A-B) y (B-C), 
pues tienen el mismo atributo X. Por otra parte, su cardinalidad, según las tablas, 
puede valer, en el sentido de Aa C, n,m,có 1, y de Ca A lo mismo. La cardinalidad 
dada es (c:c), que no contradice a estos valores. Sin embargo, si eliminamos del 
diagrama la asociación (A-C), perderíamos información sobre su cardinalidad. Por 
tanto, no es redundante incluirla en el dibujo. 


16) En el diagrama siguiente, hallar las cardinalidades posibles de la asociación implícita 
entre A y C y decir si es redundante: 


A (X,Y) 


Aplicando la tabla de composición de cardinalidades se obtiene que la cardinalidad 
entre A y C es (1:1). Por tanto, la cardinalidad está completamente definida, por lo 
que es redundante incluir la asociación entre A y C en el dibujo. 


También se puede obtener la cardinalidad observando que X debe ser clave en A y 
en C (por la regla de Definición de Claves). Esto implica que las cardinalidades 
buscadas no pueden ser múltiples, es decir, han de ser 1 o c. Pero c no pueden ser, 
pues todos los valores de X en A existen en C, y viceversa. Luego han de ser 1. 


17) Sea el diagrama siguiente: 


Supongamos que el bucle (R-S-T) se debe a que la asociación T es redundante con 
R y S. ¿Puede afirmarse también que R es redundante con S y T, y que S es 
redundante con R y T? 
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¿Cuál de las tres asociaciones, R, S o T, es preferible eliminar en el diagrama? 


Puesto que T es redundante con R y S, si entramos por Á, y tomamos un X, y 
recorremos el camino A-R-B-S-C, llegamos a obtener los mismos valores de Z que 
si vamos de A a C por T. Pero, por las cardinalidades dadas, si entramos por B y 
tomamos un valor Y, y recorremos el camino B-S-C-T-A, llegamos a obtener los 
mismos valores de X que si vamos de B a A directamente por R. Por el contrario, 
si entramos por C, y recorremos el camino C-T-A-R-B, asociamos a cada Z unos 
valores de Y que pueden no coincidir con los que se le asocian yendo de C a B 
directamente por S. Por tanto, R es redundante con S y T, pero S no lo es con R y T. 


Por consiguiente, S no puede ser eliminado del diagrama. En cambio, puesto que R 
y T son redundantes, podemos eliminar una cualquiera de ellas, en principio. Veamos 
qué diseño se obtiene en ambos casos. 


Si eliminamos R, el diagrama queda: 


AX) 


Se transforma en: 


GA=2=,A,Y) 


Suprimiendo rectángulos se llega a: C(-Z-, X, Y). Por otra parte, por las cardinalida- 
des dadas debe cumplirse en la relación C la dependencia Y >X, por lo que C no 
está normalizada. 


Para normalizarla, la proyectamos sobre Y, X, y sobre Y, Z. Sean B(Y, X) y C(Y, Z) 
estas proyecciones. El diseño estará en definitiva formado por las relaciones: B(-Y—, X), 
C(Z-, Y). 


Veamos ahora qué diseño se obtiene si eliminamos T en el diagrama inicial. Este 
queda así: 


A(X) B (Y) C(Z) 


Se transforma en: 
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Se llega directamente al mismo diseño normalizado que antes. 


METODO Y EJEMPLOS 


En los ejercicios siguientes, para simplificación de los dibujos, dejaremos a veces las 
asociaciones explícitas sin nombre. En este caso indicaremos que son explícitas adjuntán- 
doles el signo éz. También, por la misma razón, se omitirán a veces los nombres de los 
conjuntos de valores representados en los rectángulos. 


1) Sean los conjuntos de valores siguientes. 


C1 (NE): Nombres de los empleados de una empresa. 
C2 (4D): Números identificadores de los departamentos de la empresa. 
C3 (ND): Nombres de los departamentos de la empresa. 
C4 (4 T): Números de teléfono, dentro de la empresa, asignados a empleados. 
C5 (CJ): Código de si un empleado es jefe o no. Es un conjunto de dos valores: S 
(si es jefe), N (si no es jefe). 
Todos los empleados tienen nombres diferentes. 


Un departamento puede tener varios empleados o ninguno. Un empleado tiene que 
estar en un departamento y no puede pertenecer a más de uno. 


Un departamento no puede tener más de un jefe, aunque puede estar sin jefe en algún 
momento. 


Cada empleado tiene un teléfono. Si es jefe, lo usa en exclusiva, si no, comparte su uso 
con otros empleados no jefes. 


Representar la descripción anterior en un diagrama y obtener el esquema de diseño. 
Empecemos dibujando el diagrama: 


C2 (4D) 
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Se transforma en el siguiente: 


E (-NE=, CJ, 4ET, 4D) ] 
le 
DEP (-4+D—, —ND-—) | 


El esquema de diseño obtenido es: 


e Entidades: Empleados (EMP) y Departamentos (DEP). DEP es independiente, 
EMP depende de DEP. 


e Relaciones: Empleados EMP (-NE-, CJ, 4T, 4D) y Departamentos: 
DEP (-4D-, -ND-). En Esta última designamos 4D. como clave primaria. 


e Condiciones adicionales deducibles del diagrama: todo valor de 4D de EMP 
debe existir en DEP. 


Condiciones adicionales del enunciado no deducibles del diagrama ni utilizadas en su 
construcción: 


a) Que los jefes no comparten sus teléfonos. 
b) Que los departamentos no puedan tener más de un jefe. 


Estas condiciones, aplicadas al diseño obtenido, pueden enunciarse así: 
a) Si seleccionamos en EMP todas las filas de los jefes, el atributo 4T no se 
repite, es decir, es una clave. 


b) Si seleccionamos en EMP todas las filas de los jefes, el atributo 4D no se repite, 
es decir, es una clave. 


Para explicitar estas condiciones en el esquema de diseño hay que partir EMP en dos 
relaciones, una con los empleados jefes y otra con los no jefes. Las llamaremos EMPJ 
y EMPN. 


En ellas el atributo CJ es redundante, pues siempre toma el mismo valor. Por tanto, 
lo suprimimos. 


El diagrama final quedará entonces así: 


EMPN (-NE-, 4D, 47) | 
ol o | n 
| DEP (-4eD=, -ND-) 
(NE) | (+ T) 


o: .0 . 


EMPJ (-NE-, —4HD-, 
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El esquema de diseño obtenido es: 


e Entidades: Empleados que son jefes (EMPJ), Empleados que no son jefes 
(EMPN) y Departamentos (DEP). DEP es independiente, EMPN depende de 
DEP y EMPJ es subordinada a DEP. 


o Relaciones: Empleados no jefes:.EMPN (-NE-, 4T, 4D). Empleados jefes: 
EMPJ (-NE-, -4T-, -4D-). Departamentos: DEP (-4D-, -ND-). Claves 
primarias: NE en EMPJ y 4D en DEP. 


e Condiciones adicionales deducibles del diagrama: 
Todos los valores de 4D de EMPJ y EMPN deben existir en DEP. 
Los valores de 4T de EMPJ no pueden existir en EMPN. 
Los valores de NE de EMPJ no pueden existir en EMPN. 


Veamos otra forma de enfocar el problema. Al dibujar el diagrama inicial anterior 
pusimos cardinalidad (1:m) a la asociación entre Cl y C4, lo cual no refleja fielmente 
las condiciones dadas, pues para los jefes esta cardinalidad es (1: 1). La causa de esta 
deficiencia de representación es que dentro del conjunto de empleados hay dos 
subtipos, los que son jefes y los que no, con distintas características, que deseamos 
reflejar en nuestro modelo de datos. Para conseguirlo hay que dibujar separadamente 
a cada subtipo o categoría. 


Puesto que los teléfonos se asocian a los jefes con una cardinalidad distinta que a los 
empleados, también los clasificaremos en dos subtipos: los teléfonos asignados a jefes 
y el resto. 


De este modo tendremos los siguientes conjuntos de valores: 
e C1J (NE): Nombres de los empleados jefes. 
e CIN (NE): Nombres de los empleados que no son jefes. 
e C4J (4T): Teléfonos de jefes. 
e C4N (4T): Teléfonos de los que no son jefes. 


El diagrama inicial quedará así: 


Cc 


C4N (4 T) 


8 
m 
E “É EE ds de 
Cc 
jp 
c n 
8 
CD) 
8 
C3 (ND) 
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En este diagrama, la cardinalidad (1:c) de la asociación implícita entre C1 y C1J 
indica que C1J es un subconjunto de C1. Lo mismo es aplicable a CIN. Por otra 
parte, C1J y CIN incluyen todos los valores de Cl, por lo que éste es redundante y 
lo podemos suprimir del dibujo. Además, no hay valores comunes entre C1J y CIN. 
Esto lo expresaremos poniendo una asociación entre ellos de cardinalidad 0 (cero). 
Esto mismo es aplicable a C4, C4J y C4N. El diagrama quedará, por tanto, asi: 


Aplicando a este diagrama las reglas de transformación obtenemos el mismo esquema 
de diseño que anteriormente. 
2) Sean los conjuntos de valores siguientes: 
Cl (4M): Matrículas de los coches de una empresa asignados a sus vendedores. 
C2 (MO): Modelos de estos coches. 
C3 (4V): Identificadores de vendedores. 
C4 (NV): Nombres de vendedores. 


La empresa dispone de una flota de coches para sus vendedores. A cada vendedor se 
le asigna un coche, y cada coche sólo se asigna a un vendedor. Sea R (4M, 4V) la 
asociación entre vendedores y coches. 


Representar esta descripción en un diagrama y obtener el esquema de diseño. 
Diagrama de partida: 
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Se transforma en: 


(4 M-, MO) 


Agregando se transforma en un solo rectángulo, que da lugar a un esquema con una 
sola relación 


Vendedores: VEN 4 V-, NV, -4 M-—, MO). 


Como ya se ha dicho al describir el método de diseño, conviene validar el esquema 
obtenido comprobando si las Entidades corresponden con conceptos lógicos del 
mundo real que queremos representar, y cómo respondería a posibles cambios en las 
cardinalidades. 


En nuestro caso, la entidad obtenida, VEN, tiene datos mezclados de vendedores y 
de coches. Esto se debe a que la cardinalidad de R es (1: 1). Si esto fuera a mantenerse 
así rigurosamente en el futuro, es correcto considerar los atributos de coches como 
parte de la Entidad Vendedor. 


Supongamos, sin embargo, que algún día pudiera cambiar el criterio de asignación de 
coches a los vendedores, permitiendo que un coche fuera compartido por varios de 
ellos. Además, algunos coches pueden estar sin asignar ningún vendedor durante un 
período de tiempo. 


¿Cómo modificaría esto al diseño obtenido? Tendríamos el diagrama de partida: 


(=4eV—, NV) 


Se transforma en: 


VEN (-4eV—, NV, 34M) 
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De este modo obtenemos el esquema: 


e Entidades: Coches (CCH) y Vendedores (VEN). CCH es independiente, VEN 
depende de CCH. 


e Relaciones: Vendedores: VEN (-4 V-, NV, 4 M). Coches: CCH 4 M-, MO). 


e Condiciones deducibles del diagrama: Todos los valores de 4 M de VEN deben 
existir en CCH. 


3) La Regla de Propagación de Claves, tal como se enunció en el capítulo correspondien- 
te, se aplica entre dos rectángulos ligados por una asociación explícita de cardinalidad 
(1:n). Demostrar que también puede aplicarse cuando la cardinalidad es (c:n) si 
permitimos que el atributo propagado tome valores nulos. 


el 
n 


Transformemos la asociación explícita R en implícita: 


Sea el diagrama siguiente: 
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Apliquemos ahora la Regla de Agregación de rectángulos generalizada para valores 
nulos. Si S es la yunción externa entre A y R, el diagrama queda: 


S (-X-,X1,Y) 


La clave Y se ha propagado a S, pero puede tener valores nulos. Obsérvese además 
que la cardinalidad original, (c:n), se ha transformado en (1: n), significando que todos 
los valores de Y de S que no son nulos existen en B. 


4) Queremos diseñar una Base de Datos para almacenar información sobre los Departa- 
mentos, Empleados y Oficinas de una empresa. Sus identificadores respectivos son 
4D, AE y AO. Por cada Departamento se desea almacenar su presupuesto (lo 
designaremos por PD) en pesetas, y el número identificador del empleado que lo dirige. 
También se desea guardar por Departamento los identificadores de sus empleados, los 
de las oficinas que ocupa y los Proyectos de los que cada Departamento es responsable. 
Los proyectos tienen un identificador llamado 4P. Para cada empleado se deseasaber 
los proyectos a los que está asignado, la oficina donde está su puesto de trabajo, y 
por tanto donde recibe su correspondencia, y su número de teléfono en dicha oficina. 
Cada proyecto tiene un presupuesto, llamado PP, en pesetas, no incouyendo en el del 
Departamento responsable del proyecto. Cada oficina tiene una superficie en metros 
cuadrados que se desea almacenar también, con el nombre SO. Para cada empleado 
se desea guardar una información histórica de los aumentos salariales que ha tenido, 
independientemente de si han ido acompañados de ascenso o no. Por cada subida de 
sueldo se guardará la fecha en que se ha producido (la llamaremos FS), la categoría 
profesional del empleado en ese momento (CP) y el nuevo sueldo en pesetas (NS). 
También se desea saber para cada oficina sus números de teléfono (los números de 
teléfono los designaremos como 4T). Un Departamento puede tener varios emplea- 
dos, proyectos y oficinas, pero a cada uno de éstos sólo corresponde un Departamento. 
Un teléfono está en una oficina. Una oficina puede tener varios teléfonos. 


Obtener el esquema relacional de diseño de la Base de Datos de acuerdo con esta 
descripción, completándola si hace falta con las hipótesis adicionales que se crean 
razonables. 


Partimos del siguiente diagrama: 
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DO 


(44 E,NS) 


El significado de los nombres de las relaciones explícitas es el siguiente: 
RESPONSABLE-DE: Asocia cada Departamento con los Proyectos de que es 
responsable. 

JEFE: Asocia cada Departamento con el empleado que lo dirige. 


TIENE: Asocia cada Departamento con los empleados que le pertenecen adminis- 
trativamente. 


ESTA-EN: Asocia cada Departamento con las oficinas en que está instalado. 
ASIGNADO: Asocia cada empleado con los proyectos en los que trabaja. 
PUESTO: Asocia cada empleado con la oficina donde se encuentra instalado. 
OT: Asocia a cada oficina con sus teléfonos. 

ET: Asocia a cada empleado con su teléfono. 


Parece razonable suponer que la asociación TIENE es redundante con ESTA-EN y 
PUESTO. La podemos eliminar del dibujo. A su vez, PUESTO es redundante con 
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OT y ET. Después de eliminarla y transformando el diagrama anterior, se obtiene el 
siguiente: 


TEL 
(4 T-, 440) 


EMP 
(4 E, AT) 


EMPPRO 
(EE, AP) 


Obtenemos, por tanto, el diseño siguiente: 


a) Entidades: Departamentos (DEP), Oficinas (OFT), Teléfonos (TEL), Empleados 
(EMP), Proyectos (PRO), Empleados asignados a Proyectos (EMPPRO),Histo- 
ria de subidas salariales de los empleados (HIS). 


Entidades independientes: Ninguna. Entidades débiles: OFI, TEL, EMP, PRO 
y HIS. Entidades asociativas: DEP, EMPPRO. DEP es una Entidad subordina- 
da a EMP. 


b) Relaciones: 


DEP (-4D-, -AE-, PD), (4 E: identificador del jefe del Departamento); 
OFI (-40-, 4D, SO); 

EMP -AE-, AT); 

PRO EXP-, 4D, PP); 

HIS +4E, NS-, CP, FS); 

EMPPRO (E, 4P). 

En DEP designamos a 4D como clave primaria (más estable que 4E). 


c) Condiciones adicionales expresadas en el diagrama: 


Los valores de 4D en OFI deben existir en DEP, y viceversa. 
Los valores de 40O en TEL deben existir en OFI, y viceversa. 
Los valores de 4T en EMP deben existir en TEL. 

Los valores de 4E en DEP deben existir en EMP. 

Los valores de 4D en PRO deben existir en DEP. 

Los valores de 4E en EMPPRO deben existir en EMP. 
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Los valores de 4P en EMPPRO deben existir en PRO. 
Los valores de 4E en HIS deben existir en EMP. 


d) Condición no expresada en el diagrama: (4 E, FS) es una clave en HIS. 


5) Queremos diseñar una Base de Datos para almacenar información sobre nuestros 
Clientes y sus Pedidos, cuyos identificadores respectivos son 4C y AP. Los artículos 
comercializados por nuestra organización tienen un identificador llamado XA. Algu- 
nos son fabricados en factorías propias, cuyo identificador es F, y otros hay que 
adquirirlos en proveedores externos. Cada cliente dispone de un crédito cuyo límite 
se llama LC, de un descuento llamado DC por compras masivas, y de un saldo, SC, 
cuyo importe varía conforme va pagando los pedidos entregados. Los pedidos se 
entregan en una dirección de entre varias posibles de cada cliente. Estas direcciones 
de llaman DE (dirección de entrega). Los pedidos se componen de dos partes: una 
cabecera de pedido y varias líneas de detalle. En la cabecera figuran la fecha del pedido 
que lo hace. Las líneas de detalle contienen el artículo pedido y la cantidad pedida. 
Se desea guardar toda esta información en la Base de Datos. Cada artículo tiene una 
descripción única. Se desea también llevar un control de las necesidades de fabricación. 
Para ello, por cada fábrica propia se guardará el nivel de inventario en el almacén de 
la fábrica de cada artículo (CD: Cantidad Disponible) y el nivel mínimo de existencias 
a partir del cual hay riesgo de quedarse sin existencias (NR: Nivel de Riesgo). Un 
pedido puede servirse en varias entregas. Para llevar un control de éstas, se guardará 
por cada línea de detalle un contador, con lo que queda pendiente de entregar en cada 
momento, que se llama PE. 


Obtener el esquema relacional de diseño de la Base de Datos de acuerdo con esta 
descripción, completándola si hace falta con las hipótesis adicionales que se crean 
razonables. 


Partimos del siguiente diagrama: 
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El significado de los nombres de las relaciones explícitas es el siguiente: 
CDE: Asociación (Cliente-Dirección de envío). Asocia a cada cliente con todas sus 
posibles direcciones de recepción de pedidos. 7 


DEP: Asociación (Direción de envíio-Pedido). Asocia a cada pedido con la direc- 
ción donde hay que entregarlo. 


CP: Asociación (Cliente-Pedido). Asocia a cada cliente con sus pedidos. 
Es lógico suponer que la asociación CP es redundante con CDE y DEP. La 


eliminamos del dibujo. Aplicando a éste las reglas de transformación se obtiene el 
siguiente: 


CLI 
(=4C—, SC, DC, LC) 


PED 
(=4P-, FP, DE) | 


LIN 
(=4P, A4ÉEA-, CP, PE) 


EXI 
(=4F, ÁÉA—, CD, NR) 


Obtenemos por tanto el diseño siguiente: 


a) Entidades: Clientes (CLI), Direcciones de recepción de pedidos (DIR), Pedidos 
(PED), Líneas de detalle de los pedidos (LIN), Artículos (ART), Existencias en los 
almacenes de las fábricas propias (EXI. 


Entidades independientes: CLI, ART. Entidades débiles: DIR, EXI. Entidades 
asociativas: PED, LIN. 


b) Relaciones: 


CLI E4C-, SC, DC, LC); 
DIR (-DE-, 4C); 

ART (E%4A-, —-DA-); 

EXI (AF, %4A-, CD, NR); 
PED (-4P-, FP, DE); 

LIN (+4P, 4A-—, CP, PE). 
Clave primaria en ART: 4A. 
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c) Condiciones adicionales expresadas en el diagrama: 


Los valores de 4C en DIR deben existir en CLI. 
Los valores de DE en PED deben existir en DIR. 
Los valores de 4P en LIN deben existir en PED, y viceversa. 
Los valores de 4A en LIN deben existir en ART. 
Los valores de 4A en EXI deben existir en ART. 


d) Condiciones adicionales no expresadas en el diagrama: 


Los valores de PE no deben superar a los de CP. 
Los valores de LC no deben superar a 0, ni a los de SC. 
Los valores de CP, PE, NR, DC y CD no pueden ser negativos. 
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Obras generales 


ABRAMSON.— Teoría de la información y codificación. 

ANGULO y ZAPATER.-— Introducción a la informática. 

BANKS.— Microordenadores. Cómo funcionan. Para qué sirven. 

COHEN.— Estructura lógica y diseño de programas. 

FLORES.-— Estructuración y proceso de datos. 

GALAN-CORDERO.— Teleinformática. 

GARCIA SANTESMASES.-— Cibernética. Aspectos y tendencias actuales. 

GARDARIN.— Bases de datos. 

GOSLING.— Códigos para ordenadores y microprocesadores. 

HARTMAN.— Manual de los sistemas de información. 2 tomos. 

HUNT.-— Manual de informática básica. 

HURTADO MERELO.-— 200 problemas de informática. 

INTERTAGLIA — Guía práctica del comando numérico. 

LEWIS.— Estructuras de datos. Programación y aplicaciones. 

LUCAS.-— Sistemas de información. Análisis. Diseño. Puesta a punto. 

MENASCE.— Redes de computadores. 

PEREZ-LEMAUR.— Diagramas de flujo. Ejercicios y problemas. 

POPKIN.— Introducción al proceso de datos. 

PUJOLLE.— Telemática. 

RODRIGUEZ.-— Protección de la información. Diseño de criptosistemas informá- 
ticos. 

SCHMIDT.— Introducción a los ordenadores y al proceso de datos. 


Diccionarios 


HART.-— Diccionario del Basic. 

NANIA .— Diccionario de Informática. Inglés, francés, español. Más de 11.000 tér- 
minos. Cartoné 

OLIVETTI.— Diccionario de Informática. Inglés-Español. 


Lenguajes 


ALONSO.— Técnicas de programación. Programación estructurada. Pascal. Estruc- 
turas de datos. 

BELLIDO y SANCHEZ.-— Basic para estudiantes. 

BELLIDO y SANCHEZ.— Basic para Maestros. 

BELLIDO.— Basic para maestros (Libro y casete) 

BURKE.-— Enseñanza asistida por ordenador. 

CECIL.— Depuración de programas en BASIC. 

CUÑAT.- Pascal para estudiantes. 

CUÑAT.— Pascal y Turbopascal. Programas y prácticas. 

CHECROUN.-— Basic. Programación de microordenadores. 

DAX.— Lenguaje C. 

DELANNOY.-— Ficheros en Basic. 

GALAN PASCUAL.— MODULA 2. Desarrollo de Software. (Con disquete). 

GALAN PASCUAL. .— Pascal y turbopascal. 

GALAN PASCUAL.— Programación con el lenguaje Cobol. 

GARCIA MERAYO.-— Programación en Fortran 77. 

GOMEZ, DEL PINO.— Curso completo de BASIC. T.I. Fundamentos. 

GOMEZ, DEL PINO.— Curso completo de BASIC. T. II. Métodos. 

GOMEZ, DEL PINO.— Curso completo de BASIC. T.III. Ficheros. 


HURTADO MERELO.-— Cobol con programación estructurada. Curso acelerado. 

HURTADO MERELO.-— Lenguaje Cobol con programación estructurada. 

HURTADO MERELO.— Programas Cobol. Incluye ejercicios de programación es- 
tructurada. 

LARRECHE.- Basic. Introducción a la programación. 

LEPAPE.— Programación del Z80 con ensamblador. 

MARSHALL. -— Lenguajes de programación para Micros. 

Mc NITT.— Simulación con ordenador. 

MONTEIL.-— Primeros pasos en Logo. 

MORALES.-— Problemas resueltos de programación estructurada. 

NUÑEZ, GARCIA, COLLADO, HERNANDEZ.— Logo. Aprender a pensar. 

OAKEY — Lenguajes Forth para micros. 

QUANEAUX.-— Tratamiento de textos con Basic. 

QUEINNEC.-— Programación en Lisp. 

RAMON.— 44 Superprogramas en Basic. 

ROSSI.— Basic. Curso acelerado. 

SANCHIS y MORALES.— Programación con el lenguaje Pascal. 

SARAM, DE.— Programación en micro-prolog. Un lenguaje de la 54 generación. 

WATT y MANGADA.— Basic avanzado para niños. 

WATT y MANGADA.-— Basic para niños. 

WATT, MANGADA y GOMEZ-MASCARAQUE.— Logo para niños. 

YOUNG.— Lenguajes en tiempo real. 


Aplicaciones profesionales 


ANGELL.— Gráficos con computador. 

ANGULO/NO.— Control de procesos industriales por computador. 
ASTROM y WITTENMA.-— Sistemas controlados por computador. 
BARRIO.-— Subrutinas para aumentar la precisión de cálculo. 
BUITELAAR.— Informática y medicina. 

CROCUS.-— Sistemas de explotación de computadores. 
GAUTHIER.— Diseño de programas para sistemas. 
GRIGORIEFF.— DBASE II DBASE llI. Guía de uso. 
GRIGORIEFF.— Informática para actividades profesionales. 
LANE.— Telemática y comunicaciones en la empresa. 
NOWAKOWSKI.— Electro BASIC. 

O"REILLY .— Ingeniería electrónica asistida por computador. 
PANNELL.— El microordenador en la pequeña empresa. 
THOMAS y DOUGLAS.— Auditoria informática. 
THORIN. — Ingeniería del Software. 

WHITAKER.— Investigación operativa con el computador. 
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ALONSO.-— dBASE Ill Plus. 

ALONSO.— Lotus 1-2-3. 
GOMEZ-MASCARAQUE, GOMEZ.— Open Access II. 
IBAÑEZ.— Wordperfect. 

KAMIN.— Disco duro. 

LOPEZ.— Multiplán.. 

LOPEZ-BAISSON.— Serie Assistant de IBM. 
LOPEZ-BAISSON.— Symphony. 

LOPEZ, GOMEZ-MASCARAQUE.— Wordstar. 
NAVAS.— Autocad. 

TORRES. — Clipper. 
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A lo largo de los últimos años se está expandiendo 
rápidamente la utilización de bases de datos relacionales en 
toda la escala de sistemas informáticos, desde los ordenadores 
personales a los grandes sistemas. Hoy día prácticamente 
todas las instalaciones informáticas necesitan profesionales 
formados en esta técnica. 


El primer paso, y de fundamental importancia para utilizar 
bien una base de datos relacional es hacer un buen diseño 
de sus estructuras de datos. A ello va encaminado el presente 
libro. En él se presentan los conceptos básicos del Modelo 
Relacional de Datos, la teoría de Normalización y un 
método de diseño basado en gráficos de Entidades, 
Relacionales y Atributos. 


E. Rivero Cornelio 


Se ha buscado un estilo didáctico en la presentación de estos 

temas. Para ello, los nuevos conceptos y definiciones se 

introducen justificándolos en función del problema que 

pretenden resolver. Se ha incluido además un gran número 

de ejemplos y ejercicios, con sus soluciones. Todo ello hace 

de este libro un valioso instrumento de aprendizaje y A 
entrenamiento tanto para los estudiantes (Facultades de 

Informática, Escuelas Técnicas, Escuelas Universitarias, etc.) 

como para los profesionales informáticos que necesiten utilizar 

bases de datos relacionales. 
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